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