Hi,
It looks pretty readable to me. Actually my first reaction was also that
why export is default false, as initially I thought some of the annotations
were used for exporting. So I assume that if for instance I use some JS
library, then eg. @JsMethod(name="bar") would specify what JS method is
called, regardless of name in Java. Is it correct?
Marcin
On Wednesday, 20 May 2015 00:18:14 UTC+2, Goktug Gokdogan wrote:
>
> Thanks for the nice summary Ray.
>
> This is still work in progress but here is the tentative list of
> annotations and details of the new semantics. Please play with it and
> continue making suggestions.
>
> *@JsConstructor*
> JsConstructor marks a constructor so that it will be the constructor
> function for the JavaScript type. Note that, there could be only one
> JsConstructor in a type and all other constructors should be delegating to
> it.
>
> public @interface JsConstructor {
> /**
> * If a constructor is exported, then it will be not be pruned by the
> compiler.
> */
> boolean export() default false;
> }
>
> *@JsMethod*
> JsMethod marks a method in a type as a method that will be directly
> translated into a JavaScript method without any obfuscation to its name.
> Note that, while instance members are slotted in the prototype, class
> members will be defined under the constructor function of the type.
>
> public @interface JsMethod {
> /**
> * Customizes the name of the method in generated JavaScript. If not
> provided, the Java name will
> * be used.
> */
> String name() default "";
>
> /**
> * If a method is exported, then it will be not be pruned by the
> compiler. Note that if the class
> * is pruned then instance members will also be pruned even they are
> exported (i.e. exporting
> * instance members doesn't prevent class pruning).
> */
> boolean export() default false;
> }
>
> *@JsProperty:*
> JsProperty marks a field in a type as a method that will be directly
> translated into a javascript property without any obfuscation to its name.
> If it is applied to a method, it will be treated as a property accessor.
> As a result, instead of translating method calls to JsProperty methods as
> method calls in JS, they will be translated as property lookups. When a
> JsProperty method implemented by a Java class, such methods will be
> generated as custom property setter and getter in JavaScript, hence the
> property access will trigger the execution of the matching getter or setter
> methods.
>
> JsProperty follows JavaBean style naming convention to extract the default
> property name. If the JavaBean convention is not followed, the name should
> be set explicitly. For example:
> @JsProperty getX() or @JsProperty isX() translates as <tt>this.x</tt>
> @JsProperty setX(int y) translates as <tt>this.x=y</tt>
>
> Note that, while non-static member are slotted in the prototype, static
> members will be defined under the constructor function of the type.
>
> public @interface JsProperty {
> /**
> * Customizes the name of the member in generated javascript. If none is
> provided;
> * <p>
> * <li>if it is field, the simple Java name will be used.
> * <li>if it is a method, the name will be generated based on JavaBean
> conventions.
> */
> String name() default "";
>
> /**
> * If a method is exported, then it will be not be pruned by the
> compiler. Note that if the class
> * is pruned then non-static members will also be pruned even they are
> exported (i.e. exporting
> * non-static methods doesn't prevent class pruning).
> */
> boolean export() default false;
> }
>
> *@JsType:*
> JsType is used to describe the JavaScript API of an object, either one
> that already exists from the external JavaScript environment, or one that
> will be accessible from the external JavaScript environment.
>
> Marking an object with JsType is similar to marking each public member of
> the class with {@link JsProperty}/{@link JsMethod}/{@link JsConstructor}
> respectively. In order for this to work correctly the JavaScript name needs
> to be unique for each member. Some unobvious ways to cause such name
> collisions are:
> * Having method or constructor overloads.
> * Using the same name for a method and a field.
> * Shadowing a field from parent.
>
> A name collision needs to be avoided by providing a custom name (e.g.
> {@link JsProperty#name}) or
> by completely ignoring the member using {@link JsIgnore}.
>
> If the JsType is marked with a prototype reference, then classes extend
> from this will use the specified prototype as opposed to the ordinary one
> (e.g. java.lang.Object).
>
> JsTypes act like JavaScriptObject in terms of castability, except when a
> prototype is specified, in which case, cast checks and instanceof checks
> will be delegated to the native JavaScript instanceof operator.
>
> public @interface JsType {
> /**
> * Customizes the name of the type in generated javascript. If not
> provided, the simple Java name
> * will be used.
> */
> String name() default "";
>
> String prototype() default "";
>
> /**
> * Setting export here is a shortcut for setting export for each
> individual member of the class.
> * TODO: might replace with export={ALL, CLASS_MEMBERS,
> INSTANCE_MEMBERS} instead.
> */
> boolean export() default false;
> }
>
> *@JsIgnore:*
> Marks a member to be ignored for JsInterop purposes.
> This is particularly useful when {@link JsType} applied to a class and
> some members are needed to be ignored as they don't comply with
> restrictions (e.g. overloading) or shouldn't be exported.
>
> public @interface JsIgnore {
> }
>
> *@JsNamespace / @JsFunction:* No changes.
>
> *@JsExport / @JsNoExport:* Deleted.
>
> On Sat, May 9, 2015 at 6:35 PM, 'Ray Cromwell' via GWT Contributors <
> [email protected] <javascript:>> wrote:
>
> 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]
> <javascript:>> 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: - *
>
> ...
--
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/a0979a8f-b56e-4e29-a54c-8972bb908f34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
