I'm attempting to follow along. No real input, other than I did not realize the (perhaps obvious) nuance of JS interop handling both importing (e.g. wrapping DOM and existing libraries) and exporting. And how callbacks are both-ish. Huh.
- Stephen On Wed, 22 Apr 2015 21:34:27 -0700 "'Goktug Gokdogan' via GWT Contributors" <[email protected]> wrote: > On Wed, Apr 22, 2015 at 3:06 AM, Jens > <[email protected]> wrote: > > > - exports vs. export is a bit misleading. One must be used > > with > >>> interfaces/classes the other with methods. That issue only > >>> exists because @Js alone has no real meaning. > >>> > >> > >> Mostly agreed though @Js alone has meaning. As there are no > >> exports, the methods can be pruned. This difference will be > >> more significant when we change the output style to be more > >> idiomatic javascript and have a closer integration with > >> Closure compiler in the future. > >> > > > > Yeah ok probably bad wording from my side. @Js is equivalent > > to @JsImport. > > > > What I wanted to express is that the export flag is kind of > > bad because its a "marker" and the act of marking something > > for export should already be covered by applying the > > corresponding annotation. So if you would have @JsExport then > > applying @JsExport automatically means that it is marked for > > export. You don't need that boolean flag then. You would end > > up with @JsExport(STATIC_MEMBERS) for types and @JsExport for > > members which seems more straight forward (yes I know > > @JsExport(STATIC_MEMBERS) applied to a member seems strange > > but you would have the same issue with @Js). > > > > Also see next inline answer. > > > > > IIUC, even if we go with the Option 1, you are arguing JsExport > should be separate than JsType. I disagree with that. With the > new semantics, JsExport requires JsType; that is better to be > explicit; when it is explicit JsExport alone doesn't have a > meaning. 'marking' on top of JsType seems better to me as an > attribute in JsType but I'll think more about that. > > > > > > > > > >> - You have to type more because it is always annotation name > >> + property + > >>> value if you can't stick with the default "@Js". > >>> > >> > >> I'm assuming you are comparing Option 1 and Option 2 (see my > >> recent email). Based on that I'm not sure which part you are > >> referring. Can you give an example? > >> > > > > I think what bugs me most are the boolean properties that are > > used as "markers", e.g. > > > > @Js(property = true) > > @JsProperty > > > > @Js(export = true, property = true) > > @JsExport @JsProperty > > > > @Js(export = false) > > @Js(ignore = true) > > @JsIgnore > > > > It simply reads better without these flags. It is not so much > > an "issue" for more complex examples, e.g. > > > > @Js(exports = ALL, namespace = GLOBAL, name = "Foo") > > @JsExport(ALL) @JsNamespace(GLOBAL) @JsName("Foo") > > > > > I think this comes to more of aesthetics and personal > preferences. Multiple annotations easily convert into an > annotation hell where you can easily hit 3 annotations for > members; and I can even come up with cases where you need even > 4: @JsExport @JsNamepace("...") @JsName("..") @JsProperty > > Also single @JsIgnore doesn't have the same level of > expressibility as setting export and ignore independently. Also > then you have the problem when you apply JsIgnore on top of > JsName or JsProperty. > > > > > > > > > >> - Can't see a good use case for splitting exports in ALL, > >>> INSTANCE_MEMBERS and STATIC_MEMBERS. When I want to export > >>> a class I want to export its public API. > >>> > >>> > >> Yes, that was my assumption as well and that's how I > >> started. But looking at real life code inside Google, > >> especially in places where the code is shared by different > >> platforms, I see people choosing to only export instance > >> members or static members. I will need to re-evaluate this > >> after we migrate all Google code to new annotations. > >> > > > > Interesting. Wondering why that is the case. Given that it is > > just a shortcut to avoid lots of @Js(ignore=true) or > > @Js(export = true) annotations it is not so much of an issue. > > However I am wondering if the shared Java code would end up > > better if we enforce the "all public API will be exported > > unless you opt out using @JsIgnore" route. For example a > > developer would then have created a static factory class and > > then choose to export that factory or not. > > > > But I guess we'll just trust the guys with the real world > > code and if you think its a good idea to have these shortcuts > > then fine. > > > > > > > >> > >>> Personally what describes JsInterop best is the alternative > >>> using the import/export concepts. So I would stick with: > >>> > >>> Import/Export types: > >>> > >>> @JsImport: can only be applied on interfaces. > >>> @JsExport: always exports all public API in a given scope > >>> (package, class, method). So no ALL, INSTANCE_MEMBER, > >>> STATIC_MEMBER distinction. @JsIgnore can be used to opt-out > >>> selectively. > >>> > >>> Configure import/export: > >>> > >>> @JsNamespace: import/export from/to namespace > >>> @JsName: workaround reserved keywords > >>> @JsProperty: mark method as JS property > >>> @JsIgnore: opt-out of export. Might even be useful for > >>> import, e.g. do not generate trampoline for annotated > >>> default method. > >>> > >>> Special constructs: > >>> > >>> @JsLiteral > >>> @JsFunction (currently it seems not to be a real function > >>> which breaks interop > >>> <https://groups.google.com/d/msg/google-web-toolkit/PHtfLTSAJDM/oJjAo3qWa7sJ> > >>> ) > >>> > >>> > >> This is the one I listed as Alternative 2 in the doc (Option > >> 3 as I re-listed in the recent email). It doesn't hold water > >> well; works well for simple but gets confusing quickly as > >> there are many gotchas. > >> > > > > Honestly I don't get the gotchas probably because I am not so > > deep into the matter. Basically you say for Javascript > > callbacks it is unclear if import or export should be used. > > But for that case we would have @JsFunction which simply does > > the right thing and you do not have to think about it. Also > > the @JsMethod annotation does not exists in the spec so not > > sure about that one. > > > > Can you give me a confusing example? > > > > > > Let me give you some examples. > - An interface that could be implemented both by javascript or > java; should be exported or imported or both? > - For the non-function callback contracts from javascript > (e.g. web component lifecycle callbacks), should they by > imported or exported? > - I can apply JsExport at class level and member level; by > symmetry what happens if I apply JsImport at member level? > - Import and export concepts immediately fails to extend into > JsFunction, JsLiteral; so on one side you have > importing/exporting concept ('type' concept is lost) and on the > other-side you have completely disjoint function/literal > concept. This is really bothersome, especially if you go into > mixing annotations like JsExport and JsFunction on the same > type. > > The behavior becomes ambiguous most of the time so it is > difficult to explain (and even decide!); on the other hand the > alternatives are way simpler in this respect. > > > > > > -- J. > > > > -- > > You received this message because you are subscribed to the > > Google Groups "GWT Contributors" group. > > To unsubscribe from this group and stop receiving emails from > > it, send an email to > > [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/google-web-toolkit-contributors/0e267848-d4ec-4121-899e-a9a09b47c9e7%40googlegroups.com > > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/0e267848-d4ec-4121-899e-a9a09b47c9e7%40googlegroups.com?utm_medium=email&utm_source=footer> > > . > > > > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20150423090842.099f764a%40sh9. For more options, visit https://groups.google.com/d/optout.
