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.
*
*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, exports=STATIC_MEMBERS)cl
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 @Tar
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 @
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 b
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