>
> - 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
>> <https://groups.google.com/d/msg/google-web-toolkit/PHtfLTSAJDM/oJjAo3qWa7sJ>
>> )
>>
>>
> This is the one I listed as Alternative 2 in the doc (Option 3 as I
> re-listed in the recent email). It doesn't hold water well; works well for
> simple but gets confusing quickly as there are many gotchas.
>
Honestly I don't get the gotchas probably because I am not so deep into the
matter. Basically you say for Javascript callbacks it is unclear if import
or export should be used. But for that case we would have @JsFunction which
simply does the right thing and you do not have to think about it. Also the
@JsMethod annotation does not exists in the spec so not sure about that one.
Can you give me a confusing example?
-- J.
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/0e267848-d4ec-4121-899e-a9a09b47c9e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
