Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Ray Cromwell' via GWT Contributors]

Goktug, I though we were keeping @JsType and others as syntactic sugar?


On Tue, Apr 21, 2015 at 5:40 PM, Jens  wrote:

> Damn it, Safari crashed. So now a shorter version of my answer:
>
> First I agree that the current design has become quite confusing.
> Personally I really dislike the single @Js annotation approach because:
> - can be applied everywhere so you throw away some compile time checks
> provided by Java's @Target annotation
> - 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.
> - You have to type more because it is always annotation name + property +
> value if you can't stick with the default "@Js".
> - 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.
>
>
> 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
> 
> )
>
>
> I guess that is the cleanest you can get. Not sure what @JsOpaque is good
> for?!
>
> -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com
> 
> .
>
> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ec1A4w4sb4ZN9wpruLg7K%2BrdnQq3nC0LXtSCK2N5%3DBeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

Yes and no depending what you mean.

Before answering that I think there might have been some confusion the way
I listed the options in the doc so let me try to summarize it again.

There are 3 options.

Option 1 uses @Js annotation everywhere. There is no other annotation. The
@Js annotation can be applied to a class and in general it will behave
similar to applying the annotation to all public members (if that is what
you meant as syntactic sugar).
This is the one that is described first in the doc and it is the direction
we are heading right now.

Option 2 uses @JsType/@JsFunction/@JsLiteral for types and @JsMember for
members. @JsExport, @JsProperty, @JsMethod etc. are still gone (if that's
what you meant with syntactic sugar). @JsNamespace is still used for
setting namespaces where needed. So this is more or less the same design as
Option 1 but separates the annotation used at class level from the one used
at members.
This is listed as "Alternative 1" in the doc. Originally this was the
direction we were heading and it was described at the beginning while
Option 1 was listed as "Alternative 1". I changed the order because John
and Roberto both argued having single annotation (i.e. @Js) is simpler.

Option 3 uses @JsImport/JsExport and it is completely separate design from
the first two options.
This is listed as "Alternative 2".

Personally I am more towards Option 2 (see the pros and cons for the Option
2 in the doc) but I am getting mixed signals from outside so I need more
feedback from developers.


On Tue, Apr 21, 2015 at 6:21 PM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Goktug, I though we were keeping @JsType and others as syntactic sugar?
>
>
> On Tue, Apr 21, 2015 at 5:40 PM, Jens  wrote:
>
>> Damn it, Safari crashed. So now a shorter version of my answer:
>>
>> First I agree that the current design has become quite confusing.
>> Personally I really dislike the single @Js annotation approach because:
>> - can be applied everywhere so you throw away some compile time checks
>> provided by Java's @Target annotation
>> - 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.
>> - You have to type more because it is always annotation name + property +
>> value if you can't stick with the default "@Js".
>> - 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.
>>
>>
>> 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
>> 
>> )
>>
>>
>> I guess that is the cleanest you can get. Not sure what @JsOpaque is good
>> for?!
>>
>> -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com
>> 
>> .
>>
>> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ec1A4w4sb4ZN9wpruLg7K%2BrdnQq3nC0LXtSCK2N5%3DBeQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this 

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

On Tue, Apr 21, 2015 at 5:40 PM, Jens  wrote:

> Damn it, Safari crashed. So now a shorter version of my answer:
>
> First I agree that the current design has become quite confusing.
> Personally I really dislike the single @Js annotation approach because:
> - can be applied everywhere so you throw away some compile time checks
> provided by Java's @Target annotation
>

Agreed.

- 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.


> - 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?


> - 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.


>
> 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
> 
> )
>
>
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.


>
> I guess that is the cleanest you can get. Not sure what @JsOpaque is good
> for?!
>
>
It is not committed: https://gwt-review.googlesource.com/#/c/12210/
The description in the patch needs an update but in most simple terms, it
is used to mark parameters that are only intended to be used as opaque
object in javascript side. This will prevent accidental passing of types
that are not usable in javascript while it will give us more room in
changing the behavior for non-jstype parameters in the future.



> -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com
> 
> .
> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3tJODfbstJC%3DnUxd0-q_t%3DS0SuK4V%3DYgn-yRKdAH9T4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Julien Dramaix]

I'm really more in favor of the second options because (in addition to
Jens' arguments):
- it's more readable to have several meaningful annotations than one with
several parameters. And I think it's more Javaish. simple example :
@JsIgnore vs @Js(ignore=true)
- IMO, the option 1 won't be simpler to learn for developper and I think
instead it will be more confusing for the gwt developers. Most  of
parameters on the annotations cannot be used simultaneously and can be used
only on specific case (for instance: exports parameter has only a meaning
when the annotation is on type)




On Wed, Apr 22, 2015 at 6:06 AM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Yes and no depending what you mean.
>
> Before answering that I think there might have been some confusion the way
> I listed the options in the doc so let me try to summarize it again.
>
> There are 3 options.
>
> Option 1 uses @Js annotation everywhere. There is no other annotation. The
> @Js annotation can be applied to a class and in general it will behave
> similar to applying the annotation to all public members (if that is what
> you meant as syntactic sugar).
> This is the one that is described first in the doc and it is the direction
> we are heading right now.
>
> Option 2 uses @JsType/@JsFunction/@JsLiteral for types and @JsMember for
> members. @JsExport, @JsProperty, @JsMethod etc. are still gone (if that's
> what you meant with syntactic sugar). @JsNamespace is still used for
> setting namespaces where needed. So this is more or less the same design as
> Option 1 but separates the annotation used at class level from the one used
> at members.
> This is listed as "Alternative 1" in the doc. Originally this was the
> direction we were heading and it was described at the beginning while
> Option 1 was listed as "Alternative 1". I changed the order because John
> and Roberto both argued having single annotation (i.e. @Js) is simpler.
>
> Option 3 uses @JsImport/JsExport and it is completely separate design from
> the first two options.
> This is listed as "Alternative 2".
>
> Personally I am more towards Option 2 (see the pros and cons for the
> Option 2 in the doc) but I am getting mixed signals from outside so I need
> more feedback from developers.
>
>
> On Tue, Apr 21, 2015 at 6:21 PM, 'Ray Cromwell' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> Goktug, I though we were keeping @JsType and others as syntactic sugar?
>>
>>
>> On Tue, Apr 21, 2015 at 5:40 PM, Jens  wrote:
>>
>>> Damn it, Safari crashed. So now a shorter version of my answer:
>>>
>>> First I agree that the current design has become quite confusing.
>>> Personally I really dislike the single @Js annotation approach because:
>>> - can be applied everywhere so you throw away some compile time checks
>>> provided by Java's @Target annotation
>>> - 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.
>>> - You have to type more because it is always annotation name + property
>>> + value if you can't stick with the default "@Js".
>>> - 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.
>>>
>>>
>>> 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
>>> 
>>> )
>>>
>>>
>>> I guess that is the cleanest you can get. Not sure what @JsOpaque is
>>> good for?!
>>>
>>> -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com
>>> 

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Jens]

>
> - 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.

 
 

> - 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")


 

> - 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 
>> 
>> )
>>
>>
> 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?
 

-- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/0e267848-d4ec-4121-899e-a9a0

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

On Wed, Apr 22, 2015 at 3:06 AM, Jens  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
>>> 
>>> )
>>>
>>>
>> This is the one I listed a

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Stephen Haberman]

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"
 wrote:

> On Wed, Apr 22, 2015 at 3:06 AM, Jens
>  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.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Marcin Okraszewski]

I agree - I much more prefer the separate annotations. 

Regards,
Marcin Okraszewski

On Wednesday, 22 April 2015 11:47:41 UTC+2, Julien Dramaix wrote:
>
> I'm really more in favor of the second options because (in addition to 
> Jens' arguments):
> - it's more readable to have several meaningful annotations than one with 
> several parameters. And I think it's more Javaish. simple example : 
> @JsIgnore vs @Js(ignore=true)
> - IMO, the option 1 won't be simpler to learn for developper and I think 
> instead it will be more confusing for the gwt developers. Most  of 
> parameters on the annotations cannot be used simultaneously and can be used 
> only on specific case (for instance: exports parameter has only a meaning 
> when the annotation is on type)
>
>
>
>
> On Wed, Apr 22, 2015 at 6:06 AM 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com > wrote:
>
>> Yes and no depending what you mean.
>>
>> Before answering that I think there might have been some confusion the 
>> way I listed the options in the doc so let me try to summarize it again.
>>
>> There are 3 options.
>>
>> Option 1 uses @Js annotation everywhere. There is no other annotation. 
>> The @Js annotation can be applied to a class and in general it will behave 
>> similar to applying the annotation to all public members (if that is 
>> what you meant as syntactic sugar).
>> This is the one that is described first in the doc and it is the 
>> direction we are heading right now.
>>
>> Option 2 uses @JsType/@JsFunction/@JsLiteral for types and @JsMember for 
>> members. @JsExport, @JsProperty, @JsMethod etc. are still gone (if 
>> that's what you meant with syntactic sugar). @JsNamespace is still used 
>> for setting namespaces where needed. So this is more or less the same 
>> design as Option 1 but separates the annotation used at class level from 
>> the one used at members.
>> This is listed as "Alternative 1" in the doc. Originally this was the 
>> direction we were heading and it was described at the beginning while 
>> Option 1 was listed as "Alternative 1". I changed the order because John 
>> and Roberto both argued having single annotation (i.e. @Js) is simpler.
>>
>> Option 3 uses @JsImport/JsExport and it is completely separate design 
>> from the first two options.
>> This is listed as "Alternative 2".
>>
>> Personally I am more towards Option 2 (see the pros and cons for the 
>> Option 2 in the doc) but I am getting mixed signals from outside so I need 
>> more feedback from developers.
>>
>>
>> On Tue, Apr 21, 2015 at 6:21 PM, 'Ray Cromwell' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com > wrote:
>>
>>> Goktug, I though we were keeping @JsType and others as syntactic sugar?
>>>
>>>
>>> On Tue, Apr 21, 2015 at 5:40 PM, Jens >> > wrote:
>>>
 Damn it, Safari crashed. So now a shorter version of my answer:

 First I agree that the current design has become quite confusing. 
 Personally I really dislike the single @Js annotation approach because:
 - can be applied everywhere so you throw away some compile time checks 
 provided by Java's @Target annotation
 - 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.
 - You have to type more because it is always annotation name + property 
 + value if you can't stick with the default "@Js".
 - 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.


 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 
 
 )


 I guess that is the cleanest you can get. Not sure what @JsOpaque is 
 good for?!

 -- 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 
 google-web-t

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Marcin Okraszewski]

Hi,
I can a bit give my perspective as I understood @JsType and @JsExport 
seeing it only on conference presentations. It most likely is quite off the 
intended semantics:
- @JsType - bridge when initiative is started by GWT code. So, we call JS 
and get JS object from it. Or we want to pass object to JS function. But JS 
cannot call it without getting object from GWT. 
- @JsExport - where the initiative of invoking is on JS side. So, JS code 
doesn't need to have any object passed from GWT. It out of the blue calls 
some method or creates a GWT object. 

I thought that once I annotate a class (and constructor) with @JsExport, 
then JS code will be able to instantiate object and interact with it, 
without @JsType annotation.

My personal taste on annotations is that the name should describe major 
action it is causing. The parameters should be attributes that fine tune 
it, but you should not look into parameters to figure it out what it does. 
So, overriding name and namespace in JsExport is fine to me, as it exports 
under specific namespace and name. Though, the question what is the main 
purpose of @JsMember? It just tells we will do something with it, but you 
need to read parameters to understand if it won't be exported or it will be 
seen as property. Therefore, I would rather still split @JsMember into 
supported cases: @JsProperty, @JsIgnore (don't know why this one is not 
expressive enough), ... . It is like a meta method call. Method name should 
tell what it does and parameters are inputs to execution, but perfectly 
don't have a lot of distinct execution path based on values. 

Marcin

On Thursday, 23 April 2015 06:34:50 UTC+2, Goktug Gokdogan wrote:
>
>
>
> On Wed, Apr 22, 2015 at 3:06 AM, Jens > 
> 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 

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Ray Cromwell' via GWT Contributors]

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  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
>> 
>> needs to be supported)

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

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 this.x
  @JsProperty setX(int y) translates as this.x=y

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;
   * 
   * if it is field, the simple Java name will be used.
   * 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.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

Here is the comparison chart:


@JsExport @JsType

class MyClass {}

@JsType(exports=ALL)

class MyClass {}

@JsExport

class MyClass {}

@JsType(exports=STATIC_MEMBERS)

class MyClass {}

@JsExport(“Name”)

class MyClass {}

@JsType(name=”Name”, exports=STATIC_MEMBERS)

class MyClass {}

@JsExport(“Name”) @JsType

class MyClass {}

@JsType(name=”Name”, exports=ALL)

class MyClass {}

@JsType

class MyClass {}

@JsType(exports=INSTANCE_MEMBERS)

class MyClass {}

@JsType

interface MyInterface{}

@JsType(exports=INSTANCE_MEMBERS)

interface MyInterface{}

@JsType

interface ImportedLibrary{}

@JsType

interface ImportedLibrary{}

@JsType

interface ImportedLibraryCallback{}

@JsType(exports=INSTANCE_MEMBERS)

interface ImportedLibraryCallback{}

@JsExport

SomeConstructor{}
@JsExport

static void someStaticMethod{}
@JsExport

static Object someStaticField;

@JsConstructor(export=true)

SomeConstructor{}
@JsMethod(export=true)

static void someStaticMethod{}
@JsProperty(export=true)

static Object someStaticField;

@JsExport(“someName”)

static void someStaticMethod{}
@JsExport(“someName”)

static Object someStaticField;

@JsMethod(name=”someName”, export=true)

static void someStaticMethod{}
@JsProperty(name=”someName”, export=true)

static Object someStaticField;

@JsNoExport

static void someStaticMethod{}

@JsMethod(export=false) or @JsIgnore

static void someStaticMethod{}

@JsNoExport

void someMethod{}

@JsIgnore

void someMethod{}

@JsProperty

void someMethod{}

@JsProperty

void someMethod{}

@JsProperty(“someName”)

int someField;
@JsProperty(“someName”)

void someMethod{}

@JsProperty(name = “someName”)

int someField;
@JsProperty(name = “someName”)

void someMethod{}

On Tue, May 19, 2015 at 3:17 PM, 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 this.x
>   @JsProperty setX(int y) translates as this.x=y
>
> 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;
>* 
>* if it is field, the simple Java name will be used.
>* 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

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Juan Pablo Gardella]

Why export is defaulted to false?

On 19 May 2015 at 19:21, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Here is the comparison chart:
>
>
> @JsExport @JsType
>
> class MyClass {}
>
> @JsType(exports=ALL)
>
> class MyClass {}
>
> @JsExport
>
> class MyClass {}
>
> @JsType(exports=STATIC_MEMBERS)
>
> class MyClass {}
>
> @JsExport(“Name”)
>
> class MyClass {}
>
> @JsType(name=”Name”, exports=STATIC_MEMBERS)
>
> class MyClass {}
>
> @JsExport(“Name”) @JsType
>
> class MyClass {}
>
> @JsType(name=”Name”, exports=ALL)
>
> class MyClass {}
>
> @JsType
>
> class MyClass {}
>
> @JsType(exports=INSTANCE_MEMBERS)
>
> class MyClass {}
>
> @JsType
>
> interface MyInterface{}
>
> @JsType(exports=INSTANCE_MEMBERS)
>
> interface MyInterface{}
>
> @JsType
>
> interface ImportedLibrary{}
>
> @JsType
>
> interface ImportedLibrary{}
>
> @JsType
>
> interface ImportedLibraryCallback{}
>
> @JsType(exports=INSTANCE_MEMBERS)
>
> interface ImportedLibraryCallback{}
>
> @JsExport
>
> SomeConstructor{}
> @JsExport
>
> static void someStaticMethod{}
> @JsExport
>
> static Object someStaticField;
>
> @JsConstructor(export=true)
>
> SomeConstructor{}
> @JsMethod(export=true)
>
> static void someStaticMethod{}
> @JsProperty(export=true)
>
> static Object someStaticField;
>
> @JsExport(“someName”)
>
> static void someStaticMethod{}
> @JsExport(“someName”)
>
> static Object someStaticField;
>
> @JsMethod(name=”someName”, export=true)
>
> static void someStaticMethod{}
> @JsProperty(name=”someName”, export=true)
>
> static Object someStaticField;
>
> @JsNoExport
>
> static void someStaticMethod{}
>
> @JsMethod(export=false) or @JsIgnore
>
> static void someStaticMethod{}
>
> @JsNoExport
>
> void someMethod{}
>
> @JsIgnore
>
> void someMethod{}
>
> @JsProperty
>
> void someMethod{}
>
> @JsProperty
>
> void someMethod{}
>
> @JsProperty(“someName”)
>
> int someField;
> @JsProperty(“someName”)
>
> void someMethod{}
>
> @JsProperty(name = “someName”)
>
> int someField;
> @JsProperty(name = “someName”)
>
> void someMethod{}
>
> On Tue, May 19, 2015 at 3:17 PM, 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 this.x
>>   @JsProperty setX(int y) translates as this.x=y
>>
>> 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;
>>* 
>>* if it is field, the simple Java name will be used.
>>* if it is a method, the name will be generated base

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Colin Alworth]

At least in my cases, I'm more interested in having access to the tools and
APIs of the JS runtime within the browser and compiling my code out as
small as possible - while there are cases where I want to see my own types
exported and un-optimized, I think that might be the exception rather than
the rule.

The long term goal of JsInterop seems to be to replace JSNI and JSOs
entirely, and while there are cases of exporting that will *also* be
covered by this, exporting by default means telling the compiler "by
default, anything that interacts with the underlying browser can't be
optimized out even if you don't use it".

Reading and writing JSON from a server, wrapping browser or other JS APIs,
etc are all cases where export=false makes more sense. Exporting is also a
goal, but I suspect that considering all users of this feature, its not the
primary goal.

On Wed, May 20, 2015 at 7:16 AM Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:

> Why export is defaulted to false?
>
> On 19 May 2015 at 19:21, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> Here is the comparison chart:
>>
>>
>> @JsExport @JsType
>>
>> class MyClass {}
>>
>> @JsType(exports=ALL)
>>
>> class MyClass {}
>>
>> @JsExport
>>
>> class MyClass {}
>>
>> @JsType(exports=STATIC_MEMBERS)
>>
>> class MyClass {}
>>
>> @JsExport(“Name”)
>>
>> class MyClass {}
>>
>> @JsType(name=”Name”, exports=STATIC_MEMBERS)
>>
>> class MyClass {}
>>
>> @JsExport(“Name”) @JsType
>>
>> class MyClass {}
>>
>> @JsType(name=”Name”, exports=ALL)
>>
>> class MyClass {}
>>
>> @JsType
>>
>> class MyClass {}
>>
>> @JsType(exports=INSTANCE_MEMBERS)
>>
>> class MyClass {}
>>
>> @JsType
>>
>> interface MyInterface{}
>>
>> @JsType(exports=INSTANCE_MEMBERS)
>>
>> interface MyInterface{}
>>
>> @JsType
>>
>> interface ImportedLibrary{}
>>
>> @JsType
>>
>> interface ImportedLibrary{}
>>
>> @JsType
>>
>> interface ImportedLibraryCallback{}
>>
>> @JsType(exports=INSTANCE_MEMBERS)
>>
>> interface ImportedLibraryCallback{}
>>
>> @JsExport
>>
>> SomeConstructor{}
>> @JsExport
>>
>> static void someStaticMethod{}
>> @JsExport
>>
>> static Object someStaticField;
>>
>> @JsConstructor(export=true)
>>
>> SomeConstructor{}
>> @JsMethod(export=true)
>>
>> static void someStaticMethod{}
>> @JsProperty(export=true)
>>
>> static Object someStaticField;
>>
>> @JsExport(“someName”)
>>
>> static void someStaticMethod{}
>> @JsExport(“someName”)
>>
>> static Object someStaticField;
>>
>> @JsMethod(name=”someName”, export=true)
>>
>> static void someStaticMethod{}
>> @JsProperty(name=”someName”, export=true)
>>
>> static Object someStaticField;
>>
>> @JsNoExport
>>
>> static void someStaticMethod{}
>>
>> @JsMethod(export=false) or @JsIgnore
>>
>> static void someStaticMethod{}
>>
>> @JsNoExport
>>
>> void someMethod{}
>>
>> @JsIgnore
>>
>> void someMethod{}
>>
>> @JsProperty
>>
>> void someMethod{}
>>
>> @JsProperty
>>
>> void someMethod{}
>>
>> @JsProperty(“someName”)
>>
>> int someField;
>> @JsProperty(“someName”)
>>
>> void someMethod{}
>>
>> @JsProperty(name = “someName”)
>>
>> int someField;
>> @JsProperty(name = “someName”)
>>
>> void someMethod{}
>>
>> On Tue, May 19, 2015 at 3:17 PM, 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,

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

+1 to what Colin said.

To add to that, 'export' is for exposing something to the outside of the
binary, in time with tighter closure integration even less things will fall
outside of the binary.

On Wed, May 20, 2015 at 6:48 AM, Colin Alworth  wrote:

> At least in my cases, I'm more interested in having access to the tools
> and APIs of the JS runtime within the browser and compiling my code out as
> small as possible - while there are cases where I want to see my own types
> exported and un-optimized, I think that might be the exception rather than
> the rule.
>
> The long term goal of JsInterop seems to be to replace JSNI and JSOs
> entirely, and while there are cases of exporting that will *also* be
> covered by this, exporting by default means telling the compiler "by
> default, anything that interacts with the underlying browser can't be
> optimized out even if you don't use it".
>
> Reading and writing JSON from a server, wrapping browser or other JS APIs,
> etc are all cases where export=false makes more sense. Exporting is also a
> goal, but I suspect that considering all users of this feature, its not the
> primary goal.
>
> On Wed, May 20, 2015 at 7:16 AM Juan Pablo Gardella <
> gardellajuanpa...@gmail.com> wrote:
>
>> Why export is defaulted to false?
>>
>> On 19 May 2015 at 19:21, 'Goktug Gokdogan' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> Here is the comparison chart:
>>>
>>>
>>> @JsExport @JsType
>>>
>>> class MyClass {}
>>>
>>> @JsType(exports=ALL)
>>>
>>> class MyClass {}
>>>
>>> @JsExport
>>>
>>> class MyClass {}
>>>
>>> @JsType(exports=STATIC_MEMBERS)
>>>
>>> class MyClass {}
>>>
>>> @JsExport(“Name”)
>>>
>>> class MyClass {}
>>>
>>> @JsType(name=”Name”, exports=STATIC_MEMBERS)
>>>
>>> class MyClass {}
>>>
>>> @JsExport(“Name”) @JsType
>>>
>>> class MyClass {}
>>>
>>> @JsType(name=”Name”, exports=ALL)
>>>
>>> class MyClass {}
>>>
>>> @JsType
>>>
>>> class MyClass {}
>>>
>>> @JsType(exports=INSTANCE_MEMBERS)
>>>
>>> class MyClass {}
>>>
>>> @JsType
>>>
>>> interface MyInterface{}
>>>
>>> @JsType(exports=INSTANCE_MEMBERS)
>>>
>>> interface MyInterface{}
>>>
>>> @JsType
>>>
>>> interface ImportedLibrary{}
>>>
>>> @JsType
>>>
>>> interface ImportedLibrary{}
>>>
>>> @JsType
>>>
>>> interface ImportedLibraryCallback{}
>>>
>>> @JsType(exports=INSTANCE_MEMBERS)
>>>
>>> interface ImportedLibraryCallback{}
>>>
>>> @JsExport
>>>
>>> SomeConstructor{}
>>> @JsExport
>>>
>>> static void someStaticMethod{}
>>> @JsExport
>>>
>>> static Object someStaticField;
>>>
>>> @JsConstructor(export=true)
>>>
>>> SomeConstructor{}
>>> @JsMethod(export=true)
>>>
>>> static void someStaticMethod{}
>>> @JsProperty(export=true)
>>>
>>> static Object someStaticField;
>>>
>>> @JsExport(“someName”)
>>>
>>> static void someStaticMethod{}
>>> @JsExport(“someName”)
>>>
>>> static Object someStaticField;
>>>
>>> @JsMethod(name=”someName”, export=true)
>>>
>>> static void someStaticMethod{}
>>> @JsProperty(name=”someName”, export=true)
>>>
>>> static Object someStaticField;
>>>
>>> @JsNoExport
>>>
>>> static void someStaticMethod{}
>>>
>>> @JsMethod(export=false) or @JsIgnore
>>>
>>> static void someStaticMethod{}
>>>
>>> @JsNoExport
>>>
>>> void someMethod{}
>>>
>>> @JsIgnore
>>>
>>> void someMethod{}
>>>
>>> @JsProperty
>>>
>>> void someMethod{}
>>>
>>> @JsProperty
>>>
>>> void someMethod{}
>>>
>>> @JsProperty(“someName”)
>>>
>>> int someField;
>>> @JsProperty(“someName”)
>>>
>>> void someMethod{}
>>>
>>> @JsProperty(name = “someName”)
>>>
>>> int someField;
>>> @JsProperty(name = “someName”)
>>>
>>> void someMethod{}
>>>
>>> On Tue, May 19, 2015 at 3:17 PM, 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 pru

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Marcin Okraszewski]

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 this.x
>   @JsProperty setX(int y) translates as this.x=y
>
> 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;
>* 
>* if it is field, the simple Java name will be used.
>* 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 
> provid

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

Yes, that's correct.

On Fri, May 22, 2015 at 2:43 AM, Marcin Okraszewski 
wrote:

> 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 this.x
>>   @JsProperty setX(int y) translates as this.x=y
>>
>> 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;
>>* 
>>* if it is field, the simple Java name will be used.
>>* 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 dele

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Marcin Okraszewski]

Then +1 from me.

Marcin

On Fri, May 22, 2015 at 8:48 PM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Yes, that's correct.
>
> On Fri, May 22, 2015 at 2:43 AM, Marcin Okraszewski 
> wrote:
>
>> 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 this.x
>>>   @JsProperty setX(int y) translates as this.x=y
>>>
>>> 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;
>>>* 
>>>* if it is field, the simple Java name will be used.
>>>* 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 

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Jens]

Seems to look good. Seems pretty similar to the single @Js annotation 
version but reads better because of separate 
@JsMethod/@JsProperty/@JsConstrutor annotations and gives the possibility 
to add specific attributes to just one of them if ever needed.

Two short questions:

- JsConstrutor does not have a name attribute so maybe its worth 
documenting that you can not use JavaScript reserved words as (yes, ugly 
lower case) class names when @JsConstructor(export = true) is used?

- Currently name and export attributes are repeated through 
@JsType/Constructor/Method/Property. Is there any reason why @JsNamespace 
stands alone? For consistency I would probably convert @JsNamespace into an 
attribute as well, especially if @JsNamespace can be used with all four 
annotations.


-- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/bf832bd5-ae11-45eb-9421-bc73d5aff1a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

On Fri, May 22, 2015 at 12:22 PM, Jens  wrote:

> Seems to look good. Seems pretty similar to the single @Js annotation
> version but reads better because of separate
> @JsMethod/@JsProperty/@JsConstrutor annotations and gives the possibility
> to add specific attributes to just one of them if ever needed.
>
> Two short questions:
>
> - JsConstrutor does not have a name attribute so maybe its worth
> documenting that you can not use JavaScript reserved words as (yes, ugly
> lower case) class names when @JsConstructor(export = true) is used?
>
>
We will have a check for this but I agree it is a good idea to document
this in javadoc.


> - Currently name and export attributes are repeated through
> @JsType/Constructor/Method/Property. Is there any reason why @JsNamespace
> stands alone? For consistency I would probably convert @JsNamespace into an
> attribute as well, especially if @JsNamespace can be used with all four
> annotations.
>
>
>
Export and name attributes are always valid to set while namespace can be
set on only static members. Also we need it so that we could set the
namespace on package-info file.

An alternative solution would be introducing JsPackage annotation to use
with package-info file and introduce namespace attribute where applicable.
That would be more consistent with the rest.


> -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/bf832bd5-ae11-45eb-9421-bc73d5aff1a2%40googlegroups.com
> 
> .
>
> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3ubPeu-dZas3rs%2BtDnnVFeTRvXJur2BK2OciY9CbeMtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Goktug Gokdogan' via GWT Contributors]

FYI,

After the introduction of native JsTypes[1], the value of an explicit
"export" attribute is minimal to none.

We don't generate any code for native types anyway which is only place that
you might consider having a JsType without an export so attribute doesn't
add any value there.
If you extend a native JsType, you probably want the overridden methods
exported anyway so we are good.

I will remove them from my latest patch and submit it so that you can start
using new annotations and give us feedback.

Without the "export", everything is much simpler. I will share the updated
JsInterop doc with the latest spec this week.

Cheers.

[1]
https://groups.google.com/d/msg/google-web-toolkit-contributors/E48-XJGpz7w/kxhfiK3jAgAJ

On Fri, May 22, 2015 at 8:38 PM, Goktug Gokdogan  wrote:

>
>
> On Fri, May 22, 2015 at 12:22 PM, Jens  wrote:
>
>> Seems to look good. Seems pretty similar to the single @Js annotation
>> version but reads better because of separate
>> @JsMethod/@JsProperty/@JsConstrutor annotations and gives the possibility
>> to add specific attributes to just one of them if ever needed.
>>
>> Two short questions:
>>
>> - JsConstrutor does not have a name attribute so maybe its worth
>> documenting that you can not use JavaScript reserved words as (yes, ugly
>> lower case) class names when @JsConstructor(export = true) is used?
>>
>>
> We will have a check for this but I agree it is a good idea to document
> this in javadoc.
>
>
>> - Currently name and export attributes are repeated through
>> @JsType/Constructor/Method/Property. Is there any reason why @JsNamespace
>> stands alone? For consistency I would probably convert @JsNamespace into an
>> attribute as well, especially if @JsNamespace can be used with all four
>> annotations.
>>
>>
>>
> Export and name attributes are always valid to set while namespace can be
> set on only static members. Also we need it so that we could set the
> namespace on package-info file.
>
> An alternative solution would be introducing JsPackage annotation to use
> with package-info file and introduce namespace attribute where applicable.
> That would be more consistent with the rest.
>
>
>> -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/bf832bd5-ae11-45eb-9421-bc73d5aff1a2%40googlegroups.com
>> 
>> .
>>
>> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1Cywfrn3jH8jYPHsG0%2BiJsMg1svq%3DW%2B%2BAoBLGpgjpKAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.