There are multiple things JsInterop needs to accomplish: 1) preventing method/field renames 2) pinning methods (preventing code pruning) 3) giving a global name/namespace alias to something 4) auto-converting parameters to allow idiomatic programming 5) allowing GWT objects to extend native objects
@JsType actually combines #1/#2/#5 (although it only pins methods if the object is instantiated) @JsExport combines #2 and #3 (it not only pins a method, but treats the type as instantiable, plus it gives it a global alias) #4 is handled by @JsConvert/JsAware/JsFunction #5 is handled by @JsType(prototype="...") Goktug is trying separate out the behavior into the 5 types of interop semanics: 1) a way of indicating a method/field should not be renamed 2) a way of indicating not to prune something 3) a way of indicating giving a global alias to something 4) a way of indicating something extends a native object There are cases where you want to prevent renaming, but allow dead code elimination. You could make these separate annotations, that's matter of aesthetics, e.g. @JsPin @JsExport @JsName @JsPrototype etc On Sat, May 9, 2015 at 2:34 PM, Alex White <[email protected]> wrote: > +1 to keeping the original system. For an interface a finite number of > types > infinite number of String parameters. > Once it gets properly documented on gwtproject.org I doubt people will > consider it confusing. The problem imo is that most of the existing stuff > out there is pseudocode. > > We just started using JsInterop and the only stumbling block we > encountered was that at first we weren't using @JsNamespace. > The other thing we have found is really weird bugs in some of the > nightlies a few days ago, like types deleted from our codebase still > existing and other new types not existing. > It was from about 4-7 days ago and seems to have stopped now. It may be > related to the sourcemaps. The emergent behavior was that after a hard > cache reset Chrome would be trying to fetch a sourcemap for a deleted type. > If we grepped for that symbol in our codebase, we would find references to > it despite it being long gone in a cleanly built proj. Does the gwt > compiler keep some state information hidden somewhere on the hd? Because > that was weird. > > > > On Wednesday, April 22, 2015 at 4:42:10 AM UTC+10, Goktug Gokdogan wrote: > >> There is some upcoming changes to JsInteorp in preparation toward v1.0 >> release. >> >> The most major change is to the annotations and their meanings. Here is >> the doc explaining the changes and the reasoning. We are looking for your >> feedback, especially on alternatives. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *Issues with existing design and annotations 1. @JsExport/@JsType slicing >> is not intuitive for a lot of people esp. with gwt-exporter background. >> People are confused about when to use what.2. There is no reason to why >> @JsType doesn’t have any effect on the static methods. That is only because >> of the original use cases that the design was tackling only cared about >> well formed prototypal structures. Diving deeper into Elemental and >> different javascript output styles, ability to define the full class >> structure without exporting proves to be useful.3. @JsExport uses @JsType >> to define the prototype structure. However this imposes unnecessary >> restriction if/when there will be no javascript implementers of the @JsType >> contract. @JsType that extends non-JsType is normally ok if it is not >> implemented in js.4. You always need to fully qualify the name of the >> export even if you just want to change the simple name.The New Annotation >> SystemThere will be single annotation called @Js. Applying @Js to a member >> is making that member available in javascript without any obfuscation. >> However it is not safe from pruning if there are no references in java >> code, so one needs to put enable exporting for the type if no pruning >> wanted. Applying @Js at class level should considered as a shortcut to >> apply @Js to all members. See following chart for the attributes and their >> corresponding behavior:@JsType@Js(exports = >> INSTANCE_MEMBERS)@JsFunction@Js(mode = FUNCTION)@JsLiteral@Js(mode = >> LITERAL)@JsMethod@Js(name = "myName")@JsProperty@Js(property = >> true)@Js(name = "myName", property = true)@JsNamespace@Js(namespace = >> "mynamespace")@JsExport@Js(exports = STATIC_MEMBERS)@Js(name = “A”, exports >> = ALL)@Js(name = “A”, namespace=”a.b.c.”, exports = ALL)// When applied to >> a member@Js(export = true)@Js(name = “myName”, export = >> true)@JsNoExport@Js(ignore=true)@JsOpaque@Js(opaque=true)See Appendix below >> for a complete comparison to existing annotations.Semantics / >> Implementation in GWTImplementation: - Apply all Js names as bridge methods >> (or the reverse if Js extends Java object case >> <https://groups.google.com/a/google.com/d/msg/gwt-users/i5KCHorBC6k/6wkPSuBBXBgJ> >> needs to be supported).- Optimize away everything with regular optimization >> rules if the member is not exported.- Generate export statements for all >> pinned methods/classes.Usage: - Hybrid / Inbox use case needs to use @Js >> with exports. This will make the whole object exported and not pruned.- >> Regular library importing should use @Js with interfaces (no exports), if >> it is a callback the @Js interface should be marked as exported so the >> methods are not pruned when the object is not pruned.- Elemental needs to >> use not exported Js types with prototype set and native methods.Checks - >> mode and exports is only used in types.- export and ignore is only used in >> members.- property is only used in methods.- name is only used in members >> and types.- namespace is only used in exported static members, types and >> packages.- mode=FUNCTION cannot have any attribute set.Considered >> AlternativesAlternative 1:We could follow the above design but keep using >> old annotations for class level annotations: - @Js(mode=OBJECT) --> >> @JsType- @Js(mode=FUNCTION) --> @JsFunction- @Js(mode=LITERAL) --> >> @JsLiteral- @Js(namespace=”...”) --> @JsNamespace- @JsMember for the >> rest.Pros: - Reads well . (e.g. @JsType interface Element instead of @Js >> interface Element { .. } ).- These modes are substantially different so >> different annotations makes that explicit and helps to document.- Need to >> add additional checks as attributes are mostly disjoint. e.g exports >> doesn't apply to members, name/namespace isn't applicable for >> Js(mode=LITERAL) etc.Cons: - Multiple annotations to learn.- Using >> JsType/JsFunction/JsLiteral in the same type is forbidden but having single >> annotations automatically enforces that.Alternative 2:We can introduce two >> different concepts JsImport and JsExport. Both annotation will imply old >> JsType behavior if applied at class level. It can be applied at method >> level to provide method level customizations.The main advantage is that the >> name implies what the developer is trying to achieve. If importing a >> library or generating Elemental, @JsImport is used. For exporting code >> @JsExport is used.However, it actually make things more confusing when it >> comes to callbacks. In that case, an imported callback is actually an >> export so @JsExport should be applied instead.The main issue is, unlike the >> above designs it doesn’t let you configure your JS output without >> introducing exports.@JsType@JsImport@JsFunction@JsImport(mode = FUNCTION)// >> Another gotcha, here we are actually logically not importing always. If it >> is to call some javascript code, it is for importing but when you implement >> it in java, it is for exporting. So one can argue we should just keep it >> @JsFunction.@JsLiteral@JsExport(mode = >> LITERAL)@JsMethod{@JsImport/@JsExport}(name = "myName")// Another gotcha, >> need to choose one depending on context so we should probably stick to >> @JsExport/@JsName approach in the old design@JsProperty* >> ... > > -- > 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/50de995a-3b18-4432-9b79-76ae51940729%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/50de995a-3b18-4432-9b79-76ae51940729%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/CAPVRV7cii4dCEdLWqK_-gL%2B4nSB57fCZp2mFzJSL1BUS_7-5aQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
