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
On Fri, May 22, 2015 at 12:22 PM, Jens jens.nehlme...@gmail.com 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
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
Yes, that's correct.
On Fri, May 22, 2015 at 2:43 AM, Marcin Okraszewski okr...@gmail.com
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
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 okr...@gmail.com
wrote:
Hi,
It looks pretty readable to me.
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
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
+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 niloc...@gmail.com wrote:
At least in my cases, I'm
+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
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
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
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
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
- 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
*Appendix: Old way vs. New way@JsExport @JsTypeclass MyClass
{}@Js(exports=ALL)class MyClass {}@JsExportclass MyClass
{}@Js(exports=STATIC_MEMBERS)class MyClass {}@JsExport(“Name”)class MyClass
{}@JsExport(“a.b.c.someName”)class MyClass {}@Js(name=”Name”,
namespace=GLOBAL,
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
Goktug, I though we were keeping @JsType and others as syntactic sugar?
On Tue, Apr 21, 2015 at 5:40 PM, Jens jens.nehlme...@gmail.com 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
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
On Tue, Apr 21, 2015 at 5:40 PM, Jens jens.nehlme...@gmail.com 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
19 matches
Mail list logo
