Re: [gwt-contrib] Re: New JsInterop document

[Brandon Donnelson]

Turns out I imported the wrong JsType. Thanks for the help. 

On Wednesday, December 9, 2015 at 2:13:04 PM UTC-8, Rene Hangstrup Møller 
wrote:
>
> That is the old (and to be deleted) JsType annotation. The 
> jsinterop.annotations.JsType still has isNative as per the spec
>
> Den onsdag den 9. december 2015 kl. 22.59.30 UTC+1 skrev Brandon Donnelson:
>>
>> I noticed that isNative has been removed and exists in the doc. 
>>
>>
>> https://github.com/gwtproject/gwt/commit/d506bec0a55936fb49138e86ad7520e926c76f59
>>
>

-- 
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/7d0c900c-c63b-47db-ac5b-13580f3daa59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Rene Hangstrup Møller]

That is the old (and to be deleted) JsType annotation. The 
jsinterop.annotations.JsType still has isNative as per the spec

Den onsdag den 9. december 2015 kl. 22.59.30 UTC+1 skrev Brandon Donnelson:
>
> I noticed that isNative has been removed and exists in the doc. 
>
>
> https://github.com/gwtproject/gwt/commit/d506bec0a55936fb49138e86ad7520e926c76f59
>

-- 
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/e1facead-89c7-4dc3-ab60-b731eea2303f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Thomas Broyer]

On Wednesday, December 9, 2015 at 10:59:30 PM UTC+1, Brandon Donnelson 
wrote:
>
> I noticed that isNative has been removed and exists in the doc. 
>
>
> https://github.com/gwtproject/gwt/commit/d506bec0a55936fb49138e86ad7520e926c76f59
>

This commit is about com.google.gwt.core.client.js.JsType (i.e. the old 
annotation), not jsinterop.annotations.JsType.

-- 
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/e48b6ff3-dce7-450b-8ec7-5c659f03c79f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Brandon Donnelson]

I noticed that isNative has been removed and exists in the doc. 

https://github.com/gwtproject/gwt/commit/d506bec0a55936fb49138e86ad7520e926c76f59

-- 
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/41888d3f-231d-46de-9c8e-d7633bc15920%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

On Sun, Dec 6, 2015 at 12:38 PM, Grzegorz Nowak 
wrote:

> I've been testing JsInterop for 'export java lib to js' use case and two
> things came up:
>
> 1. Annotations have RetentionPolicy.RUNTIME which means the library I'm
> exporting must have compile time dependency on gwt-user. There are 2 ways
> to fix it: change the retention to 'source' (AutoValue does that so there
> is no need for compile time dependency on AutoValue annotations) or
> generate separate artifact with jsinterop annotations only. I guess nicer
> way to accomplish this would be the former but I'm not sure if it's
> possible. For now I'm hiding* the annotations in my base artifact.
> 2. The library I'm trying to export has several overloads of constructors
> and methods. Write now for methods I'm using @JsMethod with name to
> describe parameter types. For constructors there are 2 approaches I took so
> far. One recommended is having one @JsConstructor which is called from
> other @JsIgnored. The other approach is hiding* all constructors and
> providing single @JsConstructor Constructor(Objects...) which detects
> number of params and their types and mimics overloaded constructors. This
> generates a WARN 'unusable-by-js' which can be suppressed. Accessing such
> constructor from js works but requires wrapping of params with array: 'new
> namespace.Constructor([param1, param2, paramN]);'
>

Support for varargs will be available before RC1, so the warning will be
gone and you won't need to create an array.


>
> * by hiding I mean automatic commenting out from base source so the
> alternative artifact doesn't have them.
>
> On Friday, December 4, 2015 at 8:49:02 PM UTC+1, Goktug Gokdogan wrote:
>>
>> That's not fixed yet. Should be fixed before RC1.
>>
>> On Fri, Dec 4, 2015 at 7:23 AM, Ümit Seren  wrote:
>>
>>> I guess I can't  put native JsInterop classes and interfaces in Java
>>> Collections ?
>>> I get a ClassCastException and I checked the official JsInterop
>>> documentation and couldn't find anthing about that ?
>>>
>>>
>>> On Saturday, November 21, 2015 at 5:02:13 AM UTC+1, Goktug Gokdogan
>>> wrote:

 dramaix@ is writing such a tool; that's how we are planning to
 generate Elemental2.

 On Fri, Nov 20, 2015 at 7:56 PM, Slava Pankov  wrote:

> And it would be nice to generate java code with new jsinterop
> annotations based on typescript d.ts files. Dart team is going to 
> implement
> such tool, probably it can be adopted for GWT as well:
> https://github.com/dart-lang/sdk/issues/24874
>
>
> On Thursday, November 19, 2015 at 10:15:35 AM UTC-8, Goktug Gokdogan
> wrote:
>>
>> Instead of JsArray, you can use Object[] or JsType[] (will be ready
>> by 2.8), instead of Integer, you can Double (in 2.8 release, Double 
>> exactly
>> maps to number in javascript).
>>
>> On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley 
>> wrote:
>>
>>> We wrote our own RPC mechanism that is based entirely on JSON,
>>> mainly for performance reasons on mobile. The client works with JS 
>>> Overlay
>>> representation of the server DTO objects. We have a tool that 
>>> automatically
>>> generates the JSO's, Looking at the new interop spec's it would be 
>>> really
>>> nice for the client and server to work with the same Java DTO objects. I
>>> can see how most of it could work with the new system. However, we 
>>> handle
>>> Java object representations for ints, doubles, booleans and also
>>> enumerations by generating code in the JSO's such as :
>>>
>>> public class ContractDoJSO extends PersistentDataObjectBaseJSO {
>>>
>>>protected ContractDoJSO() {}
>>>
>>>
>>> public final native ContractType getContractTypeDv() /*-{
>>>
>>>return (this.contractTypeDv == null) ? null : 
>>> @com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
>>>
>>> }-*/;
>>>
>>>
>>> public final native void setContractTypeDv(ContractType v) /*-{ 
>>> this.contractTypeDv = (v == null) ? null : 
>>> v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;
>>>
>>>
>>> public final native java.lang.Integer getPreferredEmployerId() /*-{
>>>
>>>   return (this.preferredEmployerId == null) ? null : 
>>> @java.lang.Integer::valueOf(I)(this.preferredEmployerId);
>>>
>>> }-*/;
>>> public final native void setPreferredEmployerId(java.lang.Integer v) 
>>> /*-{
>>>
>>>  this.preferredEmployerId = (v == null) ? null : 
>>> v...@java.lang.Integer::intValue()();
>>>
>>> }-*/;
>>>
>>>
>>> In addition, if the DTO's contain arrays the client code has to
>>> access them using the JsArray class rather than the java collection 
>>> API. Do
>>> you think there is some way to have a single representation u

Re: [gwt-contrib] Re: New JsInterop document

[Thomas Broyer]

We now produce a jsinterop-annotations artifact, but our deployment to Sonatype 
OSSRH is currently broken.

-- 
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/bf823d66-e96f-421d-9f56-534275195024%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Grzegorz Nowak]

I've been testing JsInterop for 'export java lib to js' use case and two 
things came up:

1. Annotations have RetentionPolicy.RUNTIME which means the library I'm 
exporting must have compile time dependency on gwt-user. There are 2 ways 
to fix it: change the retention to 'source' (AutoValue does that so there 
is no need for compile time dependency on AutoValue annotations) or 
generate separate artifact with jsinterop annotations only. I guess nicer 
way to accomplish this would be the former but I'm not sure if it's 
possible. For now I'm hiding* the annotations in my base artifact.
2. The library I'm trying to export has several overloads of constructors 
and methods. Write now for methods I'm using @JsMethod with name to 
describe parameter types. For constructors there are 2 approaches I took so 
far. One recommended is having one @JsConstructor which is called from 
other @JsIgnored. The other approach is hiding* all constructors and 
providing single @JsConstructor Constructor(Objects...) which detects 
number of params and their types and mimics overloaded constructors. This 
generates a WARN 'unusable-by-js' which can be suppressed. Accessing such 
constructor from js works but requires wrapping of params with array: 'new 
namespace.Constructor([param1, param2, paramN]);'

* by hiding I mean automatic commenting out from base source so the 
alternative artifact doesn't have them.

On Friday, December 4, 2015 at 8:49:02 PM UTC+1, Goktug Gokdogan wrote:
>
> That's not fixed yet. Should be fixed before RC1.
>
> On Fri, Dec 4, 2015 at 7:23 AM, Ümit Seren  > wrote:
>
>> I guess I can't  put native JsInterop classes and interfaces in Java 
>> Collections ? 
>> I get a ClassCastException and I checked the official JsInterop 
>> documentation and couldn't find anthing about that ? 
>>  
>>
>> On Saturday, November 21, 2015 at 5:02:13 AM UTC+1, Goktug Gokdogan wrote:
>>>
>>> dramaix@ is writing such a tool; that's how we are planning to generate 
>>> Elemental2.
>>>
>>> On Fri, Nov 20, 2015 at 7:56 PM, Slava Pankov  wrote:
>>>
 And it would be nice to generate java code with new jsinterop 
 annotations based on typescript d.ts files. Dart team is going to 
 implement 
 such tool, probably it can be adopted for GWT as well: 
 https://github.com/dart-lang/sdk/issues/24874


 On Thursday, November 19, 2015 at 10:15:35 AM UTC-8, Goktug Gokdogan 
 wrote:
>
> Instead of JsArray, you can use Object[] or JsType[] (will be ready by 
> 2.8), instead of Integer, you can Double (in 2.8 release, Double exactly 
> maps to number in javascript).
>
> On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley  
> wrote:
>
>> We wrote our own RPC mechanism that is based entirely on JSON, mainly 
>> for performance reasons on mobile. The client works with JS Overlay 
>> representation of the server DTO objects. We have a tool that 
>> automatically 
>> generates the JSO's, Looking at the new interop spec's it would be 
>> really 
>> nice for the client and server to work with the same Java DTO objects. I 
>> can see how most of it could work with the new system. However, we 
>> handle 
>> Java object representations for ints, doubles, booleans and also 
>> enumerations by generating code in the JSO's such as :
>>
>> public class ContractDoJSO extends PersistentDataObjectBaseJSO {
>>
>>protected ContractDoJSO() {}
>>
>>
>> public final native ContractType getContractTypeDv() /*-{
>>
>>return (this.contractTypeDv == null) ? null : 
>> @com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
>>  
>>
>> }-*/;
>>
>>
>> public final native void setContractTypeDv(ContractType v) /*-{ 
>> this.contractTypeDv = (v == null) ? null : 
>> v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;
>>
>>
>> public final native java.lang.Integer getPreferredEmployerId() /*-{ 
>>
>>   return (this.preferredEmployerId == null) ? null : 
>> @java.lang.Integer::valueOf(I)(this.preferredEmployerId); 
>>
>> }-*/;
>> public final native void setPreferredEmployerId(java.lang.Integer v) 
>> /*-{ 
>>
>>  this.preferredEmployerId = (v == null) ? null : 
>> v...@java.lang.Integer::intValue()(); 
>>
>> }-*/;
>>
>>
>> In addition, if the DTO's contain arrays the client code has to 
>> access them using the JsArray class rather than the java collection API. 
>> Do 
>> you think there is some way to have a single representation using the 
>> new 
>> Interop mechanism?
>>  
>>
>> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan 
>> wrote:
>>
>>> As we are getting close to 2.8 release I wrote a new document that 
>>> is concentrating on jsinterop feat

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

That's not fixed yet. Should be fixed before RC1.

On Fri, Dec 4, 2015 at 7:23 AM, Ümit Seren  wrote:

> I guess I can't  put native JsInterop classes and interfaces in Java
> Collections ?
> I get a ClassCastException and I checked the official JsInterop
> documentation and couldn't find anthing about that ?
>
>
> On Saturday, November 21, 2015 at 5:02:13 AM UTC+1, Goktug Gokdogan wrote:
>>
>> dramaix@ is writing such a tool; that's how we are planning to generate
>> Elemental2.
>>
>> On Fri, Nov 20, 2015 at 7:56 PM, Slava Pankov  wrote:
>>
>>> And it would be nice to generate java code with new jsinterop
>>> annotations based on typescript d.ts files. Dart team is going to implement
>>> such tool, probably it can be adopted for GWT as well:
>>> https://github.com/dart-lang/sdk/issues/24874
>>>
>>>
>>> On Thursday, November 19, 2015 at 10:15:35 AM UTC-8, Goktug Gokdogan
>>> wrote:

 Instead of JsArray, you can use Object[] or JsType[] (will be ready by
 2.8), instead of Integer, you can Double (in 2.8 release, Double exactly
 maps to number in javascript).

 On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley 
 wrote:

> We wrote our own RPC mechanism that is based entirely on JSON, mainly
> for performance reasons on mobile. The client works with JS Overlay
> representation of the server DTO objects. We have a tool that 
> automatically
> generates the JSO's, Looking at the new interop spec's it would be really
> nice for the client and server to work with the same Java DTO objects. I
> can see how most of it could work with the new system. However, we handle
> Java object representations for ints, doubles, booleans and also
> enumerations by generating code in the JSO's such as :
>
> public class ContractDoJSO extends PersistentDataObjectBaseJSO {
>
>protected ContractDoJSO() {}
>
>
> public final native ContractType getContractTypeDv() /*-{
>
>return (this.contractTypeDv == null) ? null : 
> @com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
>
> }-*/;
>
>
> public final native void setContractTypeDv(ContractType v) /*-{ 
> this.contractTypeDv = (v == null) ? null : 
> v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;
>
>
> public final native java.lang.Integer getPreferredEmployerId() /*-{
>
>   return (this.preferredEmployerId == null) ? null : 
> @java.lang.Integer::valueOf(I)(this.preferredEmployerId);
>
> }-*/;
> public final native void setPreferredEmployerId(java.lang.Integer v) /*-{
>
>  this.preferredEmployerId = (v == null) ? null : 
> v...@java.lang.Integer::intValue()();
>
> }-*/;
>
>
> In addition, if the DTO's contain arrays the client code has to access
> them using the JsArray class rather than the java collection API. Do you
> think there is some way to have a single representation using the new
> Interop mechanism?
>
>
> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>
>> As we are getting close to 2.8 release I wrote a new document that is
>> concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> 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/1155c295-ecd1-4cdd-86a2-ddf3cffb618c%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/44c98d88-8d67-4f17-b942-4f7202aeac3b%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you ar

Re: [gwt-contrib] Re: New JsInterop document

[Ümit Seren]

I guess I can't  put native JsInterop classes and interfaces in Java 
Collections ? 
I get a ClassCastException and I checked the official JsInterop 
documentation and couldn't find anthing about that ? 
 

On Saturday, November 21, 2015 at 5:02:13 AM UTC+1, Goktug Gokdogan wrote:
>
> dramaix@ is writing such a tool; that's how we are planning to generate 
> Elemental2.
>
> On Fri, Nov 20, 2015 at 7:56 PM, Slava Pankov  > wrote:
>
>> And it would be nice to generate java code with new jsinterop annotations 
>> based on typescript d.ts files. Dart team is going to implement such tool, 
>> probably it can be adopted for GWT as well: 
>> https://github.com/dart-lang/sdk/issues/24874
>>
>>
>> On Thursday, November 19, 2015 at 10:15:35 AM UTC-8, Goktug Gokdogan 
>> wrote:
>>>
>>> Instead of JsArray, you can use Object[] or JsType[] (will be ready by 
>>> 2.8), instead of Integer, you can Double (in 2.8 release, Double exactly 
>>> maps to number in javascript).
>>>
>>> On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley  
>>> wrote:
>>>
 We wrote our own RPC mechanism that is based entirely on JSON, mainly 
 for performance reasons on mobile. The client works with JS Overlay 
 representation of the server DTO objects. We have a tool that 
 automatically 
 generates the JSO's, Looking at the new interop spec's it would be really 
 nice for the client and server to work with the same Java DTO objects. I 
 can see how most of it could work with the new system. However, we handle 
 Java object representations for ints, doubles, booleans and also 
 enumerations by generating code in the JSO's such as :

 public class ContractDoJSO extends PersistentDataObjectBaseJSO {

protected ContractDoJSO() {}


 public final native ContractType getContractTypeDv() /*-{

return (this.contractTypeDv == null) ? null : 
 @com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
  

 }-*/;


 public final native void setContractTypeDv(ContractType v) /*-{ 
 this.contractTypeDv = (v == null) ? null : 
 v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;


 public final native java.lang.Integer getPreferredEmployerId() /*-{ 

   return (this.preferredEmployerId == null) ? null : 
 @java.lang.Integer::valueOf(I)(this.preferredEmployerId); 

 }-*/;
 public final native void setPreferredEmployerId(java.lang.Integer v) /*-{ 

  this.preferredEmployerId = (v == null) ? null : 
 v...@java.lang.Integer::intValue()(); 

 }-*/;


 In addition, if the DTO's contain arrays the client code has to access 
 them using the JsArray class rather than the java collection API. Do you 
 think there is some way to have a single representation using the new 
 Interop mechanism?
  

 On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:

> As we are getting close to 2.8 release I wrote a new document that is 
> concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>
 -- 
 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/1155c295-ecd1-4cdd-86a2-ddf3cffb618c%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/44c98d88-8d67-4f17-b942-4f7202aeac3b%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-co

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

dramaix@ is writing such a tool; that's how we are planning to generate
Elemental2.

On Fri, Nov 20, 2015 at 7:56 PM, Slava Pankov  wrote:

> And it would be nice to generate java code with new jsinterop annotations
> based on typescript d.ts files. Dart team is going to implement such tool,
> probably it can be adopted for GWT as well:
> https://github.com/dart-lang/sdk/issues/24874
>
>
> On Thursday, November 19, 2015 at 10:15:35 AM UTC-8, Goktug Gokdogan wrote:
>>
>> Instead of JsArray, you can use Object[] or JsType[] (will be ready by
>> 2.8), instead of Integer, you can Double (in 2.8 release, Double exactly
>> maps to number in javascript).
>>
>> On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley 
>> wrote:
>>
>>> We wrote our own RPC mechanism that is based entirely on JSON, mainly
>>> for performance reasons on mobile. The client works with JS Overlay
>>> representation of the server DTO objects. We have a tool that automatically
>>> generates the JSO's, Looking at the new interop spec's it would be really
>>> nice for the client and server to work with the same Java DTO objects. I
>>> can see how most of it could work with the new system. However, we handle
>>> Java object representations for ints, doubles, booleans and also
>>> enumerations by generating code in the JSO's such as :
>>>
>>> public class ContractDoJSO extends PersistentDataObjectBaseJSO {
>>>
>>>protected ContractDoJSO() {}
>>>
>>>
>>> public final native ContractType getContractTypeDv() /*-{
>>>
>>>return (this.contractTypeDv == null) ? null : 
>>> @com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
>>>
>>> }-*/;
>>>
>>>
>>> public final native void setContractTypeDv(ContractType v) /*-{ 
>>> this.contractTypeDv = (v == null) ? null : 
>>> v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;
>>>
>>>
>>> public final native java.lang.Integer getPreferredEmployerId() /*-{
>>>
>>>   return (this.preferredEmployerId == null) ? null : 
>>> @java.lang.Integer::valueOf(I)(this.preferredEmployerId);
>>>
>>> }-*/;
>>> public final native void setPreferredEmployerId(java.lang.Integer v) /*-{
>>>
>>>  this.preferredEmployerId = (v == null) ? null : 
>>> v...@java.lang.Integer::intValue()();
>>>
>>> }-*/;
>>>
>>>
>>> In addition, if the DTO's contain arrays the client code has to access
>>> them using the JsArray class rather than the java collection API. Do you
>>> think there is some way to have a single representation using the new
>>> Interop mechanism?
>>>
>>>
>>> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>>>
 As we are getting close to 2.8 release I wrote a new document that is
 concentrating on jsinterop features to be released in 2.8:

 https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#

 Please share your feedback.

 Thanks,

 Goktug

>>> --
>>> 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/1155c295-ecd1-4cdd-86a2-ddf3cffb618c%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/44c98d88-8d67-4f17-b942-4f7202aeac3b%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%3DyUA35xvxa7i00yeGLTBS%2BqEO0zVN3Z3bYfKqhf%2BsyPGs%3DiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Slava Pankov]

And it would be nice to generate java code with new jsinterop annotations 
based on typescript d.ts files. Dart team is going to implement such tool, 
probably it can be adopted for GWT as 
well: https://github.com/dart-lang/sdk/issues/24874


On Thursday, November 19, 2015 at 10:15:35 AM UTC-8, Goktug Gokdogan wrote:
>
> Instead of JsArray, you can use Object[] or JsType[] (will be ready by 
> 2.8), instead of Integer, you can Double (in 2.8 release, Double exactly 
> maps to number in javascript).
>
> On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley  > wrote:
>
>> We wrote our own RPC mechanism that is based entirely on JSON, mainly for 
>> performance reasons on mobile. The client works with JS Overlay 
>> representation of the server DTO objects. We have a tool that automatically 
>> generates the JSO's, Looking at the new interop spec's it would be really 
>> nice for the client and server to work with the same Java DTO objects. I 
>> can see how most of it could work with the new system. However, we handle 
>> Java object representations for ints, doubles, booleans and also 
>> enumerations by generating code in the JSO's such as :
>>
>> public class ContractDoJSO extends PersistentDataObjectBaseJSO {
>>
>>protected ContractDoJSO() {}
>>
>>
>> public final native ContractType getContractTypeDv() /*-{
>>
>>return (this.contractTypeDv == null) ? null : 
>> @com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
>>  
>>
>> }-*/;
>>
>>
>> public final native void setContractTypeDv(ContractType v) /*-{ 
>> this.contractTypeDv = (v == null) ? null : 
>> v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;
>>
>>
>> public final native java.lang.Integer getPreferredEmployerId() /*-{ 
>>
>>   return (this.preferredEmployerId == null) ? null : 
>> @java.lang.Integer::valueOf(I)(this.preferredEmployerId); 
>>
>> }-*/;
>> public final native void setPreferredEmployerId(java.lang.Integer v) /*-{ 
>>
>>  this.preferredEmployerId = (v == null) ? null : 
>> v...@java.lang.Integer::intValue()(); 
>>
>> }-*/;
>>
>>
>> In addition, if the DTO's contain arrays the client code has to access 
>> them using the JsArray class rather than the java collection API. Do you 
>> think there is some way to have a single representation using the new 
>> Interop mechanism?
>>  
>>
>> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>>
>>> As we are getting close to 2.8 release I wrote a new document that is 
>>> concentrating on jsinterop features to be released in 2.8:
>>>
>>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>>
>>> Please share your feedback.
>>>
>>> Thanks,
>>>
>>> Goktug
>>>
>> -- 
>> 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/1155c295-ecd1-4cdd-86a2-ddf3cffb618c%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/44c98d88-8d67-4f17-b942-4f7202aeac3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

Instead of JsArray, you can use Object[] or JsType[] (will be ready by
2.8), instead of Integer, you can Double (in 2.8 release, Double exactly
maps to number in javascript).

On Thu, Nov 19, 2015 at 6:22 AM, Paul Stockley  wrote:

> We wrote our own RPC mechanism that is based entirely on JSON, mainly for
> performance reasons on mobile. The client works with JS Overlay
> representation of the server DTO objects. We have a tool that automatically
> generates the JSO's, Looking at the new interop spec's it would be really
> nice for the client and server to work with the same Java DTO objects. I
> can see how most of it could work with the new system. However, we handle
> Java object representations for ints, doubles, booleans and also
> enumerations by generating code in the JSO's such as :
>
> public class ContractDoJSO extends PersistentDataObjectBaseJSO {
>
>protected ContractDoJSO() {}
>
>
> public final native ContractType getContractTypeDv() /*-{
>
>return (this.contractTypeDv == null) ? null : 
> @com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
>
> }-*/;
>
>
> public final native void setContractTypeDv(ContractType v) /*-{ 
> this.contractTypeDv = (v == null) ? null : 
> v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;
>
>
> public final native java.lang.Integer getPreferredEmployerId() /*-{
>
>   return (this.preferredEmployerId == null) ? null : 
> @java.lang.Integer::valueOf(I)(this.preferredEmployerId);
>
> }-*/;
> public final native void setPreferredEmployerId(java.lang.Integer v) /*-{
>
>  this.preferredEmployerId = (v == null) ? null : 
> v...@java.lang.Integer::intValue()();
>
> }-*/;
>
>
> In addition, if the DTO's contain arrays the client code has to access
> them using the JsArray class rather than the java collection API. Do you
> think there is some way to have a single representation using the new
> Interop mechanism?
>
>
> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>
>> As we are getting close to 2.8 release I wrote a new document that is
>> concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> 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/1155c295-ecd1-4cdd-86a2-ddf3cffb618c%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%3DyUA2j3G%3D0iLTxgmo6oTZE43pEUiYOeAz%2BgmixbfsuY%2Bzekw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: New JsInterop document

[Paul Stockley]

We wrote our own RPC mechanism that is based entirely on JSON, mainly for 
performance reasons on mobile. The client works with JS Overlay 
representation of the server DTO objects. We have a tool that automatically 
generates the JSO's, Looking at the new interop spec's it would be really 
nice for the client and server to work with the same Java DTO objects. I 
can see how most of it could work with the new system. However, we handle 
Java object representations for ints, doubles, booleans and also 
enumerations by generating code in the JSO's such as :

public class ContractDoJSO extends PersistentDataObjectBaseJSO {

   protected ContractDoJSO() {}


public final native ContractType getContractTypeDv() /*-{

   return (this.contractTypeDv == null) ? null : 
@com.ocs.shared.businesslogic.contract.ContractType::valueOf(Ljava/lang/String;)(this.contractTypeDv);
 

}-*/;


public final native void setContractTypeDv(ContractType v) /*-{ 
this.contractTypeDv = (v == null) ? null : 
v...@com.ocs.shared.businesslogic.contract.ContractType::name()(); }-*/;


public final native java.lang.Integer getPreferredEmployerId() /*-{ 

  return (this.preferredEmployerId == null) ? null : 
@java.lang.Integer::valueOf(I)(this.preferredEmployerId); 

}-*/;
public final native void setPreferredEmployerId(java.lang.Integer v) /*-{ 

 this.preferredEmployerId = (v == null) ? null : 
v...@java.lang.Integer::intValue()(); 

}-*/;


In addition, if the DTO's contain arrays the client code has to access them 
using the JsArray class rather than the java collection API. Do you think 
there is some way to have a single representation using the new Interop 
mechanism?
 

On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>
> As we are getting close to 2.8 release I wrote a new document that is 
> concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>

-- 
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/1155c295-ecd1-4cdd-86a2-ddf3cffb618c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Ümit Seren]

Great thanks, that makes it much clearer. 



On Tuesday, November 17, 2015 at 5:50:13 PM UTC+1, Goktug Gokdogan wrote:
>
> If the type is native, we don't generate code for the class we assume it 
> exists somewhere. If it is not native, we generate code for the class like 
> we do for every other class. The best way to think about how jsinterop 
> works is thinking with ES6 classes.
>
> @JsTypeclass X {
>   static void m() { .. }
>   @JsProperty void setK(int k) { .. }
> }
>
> X x = new X();
> x.k = 42;
>
> ​
>
> results w/ code equlivant to following ES6 code:
>
> // JavaScript
> class X {
>   static m() { ... }
>   set k() { ... }
> }
> var x = new X();
> x.k = 42;
>
> ​
>
> if you use is isNative=true,  then it would just look like:
>
> // No class is generated, assume X is defined somewhere elsevar x = new X(); 
> x.k = 42;
>
> ​
> Also thinking them as ES6 classes is useful because then you would see 
> another problem with your example if you don't use isNative=true:
> Because there is a corresponding class, assigning instances from Object 
> literal is not safe; "{k: 42} instanceof X" is "false" even in javascript.
>
>
> On Tue, Nov 17, 2015 at 1:49 AM, Ümit Seren  > wrote:
>
>> Ok I can confirm that the issue was my fault. After moving everything to 
>> a JsTyp annotated classes, everything works fine. 
>>
>> I have a last question regarding code size and the use if isNative=true.
>> I guess isNative=true is preferred and will make sure that code size 
>> stays low by not exposing the Java contract to JS. 
>>
>> For example I have a JS library that takes configuration settings as an 
>> configuration object: 
>>
>> options = { option1:'some string',option2: 24, option3:[],..}
>>
>> and I want to use JsInterop to write a type safe wrapper for this that is 
>> only used by GWT/Java code, I would create a class like this (using 
>> isNative=true instead of just an empty @JsType): 
>>
>> @JsType(isNative=true,namespace=JsPackage.GLOBAL,name="Object")
>> public class Options {
>>public String option1;
>>public int option2;
>>...
>> }
>>
>> Thanks in advance
>>
>>
>> P.S:: Great work btw, the new JsInterop is a pleasure to work with. 
>>
>>
>> On Monday, November 16, 2015 at 12:26:32 PM UTC+1, Goktug Gokdogan wrote:
>>
>>
>>>
>>> On Mon, Nov 16, 2015 at 2:59 AM, Ümit Seren  wrote:
>>>
>>> Thanks for the info. 
>>>
>>> AFAIK JSNI syntax will go away at some point. I guess I would then rely 
>>> on a utility class to do that. 
>>>
>>>
>>> There is going to be a replacement for JSNI by supplying supplementary 
>>> js files. So if you have a class with JSNI you can still keep it future 
>>> compatible but it is a good idea to minimize such classes.
>>>  
>>>
>>> One more question: 
>>> Are there any restrictions regarding @JsProperty fields and Arrays ? 
>>>
>>> somehow following thing dosn't work (it's not set on the object , stays 
>>> undefined) 
>>>
>>> @JsProperty void setLabels(String[] labels);
>>>
>>>
>>> There is no limitation on this. Most of the time when there is such 
>>> limitation, compiler gives an error or warning.
>>> However there is a bug with respect to non public instance methods; 
>>> perhaps you are hitting that. Can you provide a full snippet so that I can 
>>> take a look?
>>>  
>>>
>>>
>>> On Friday, November 13, 2015 at 7:30:11 PM UTC+1, Goktug Gokdogan wrote:
>>>
>>>
>>>
>>> On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  wrote:
>>>
>>> Is there a way to add dynamic properties to a JsType without relying on 
>>> JSNI ? 
>>>
>>> With the experimental JSInterop version I had following solution:
>>>
>>> @JsTypinterface Options {
>>>
>>>@JsProperty void getSomeProp();
>>>
>>>@JsProperty String getSomeProp2();
>>>@JsProperty void setSomeProp2(String prop);
>>>
>>> void setSeries(String series, SeriesOptions options);
>>> }
>>>
>>> OptionsImpl implements Options {
>>>
>>>  
>>>
>>>  @Override
>>>  public final native void setSeries(String series, SeriesOptions 
>>> options) /*-{
>>>this['series'] = options;
>>>  }*-/;
>>> }
>>>
>>> Or generally what’s the best practice regarding generic JS properties ?
>>>
>>>
>>> If you are not implementing an interface with JsProperty, the best way 
>>> is simply putting a JsProperty field in your class.
>>>
>>> If you are implementing an interface, you can do what you did here but I 
>>> would recommend having a separate generic utility class so that you can 
>>> reuse what you have here in many places. We will probably provide a similar 
>>> utility class as part of jsinterop at some stage.
>>>  
>>>
>>> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan 
>>> wrote:
>>>
>>> In native types, the support for static methods are same as the support 
>>> for static fields; only overlays are supported because we don't modify the 
>>> native types. Can you give an example that works with static methods and 
>>> doesn't work with static field but should work as well? What do you m

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

If the type is native, we don't generate code for the class we assume it
exists somewhere. If it is not native, we generate code for the class like
we do for every other class. The best way to think about how jsinterop
works is thinking with ES6 classes.

@JsTypeclass X {
  static void m() { .. }
  @JsProperty void setK(int k) { .. }
}

X x = new X();
x.k = 42;

​

results w/ code equlivant to following ES6 code:

// JavaScript
class X {
  static m() { ... }
  set k() { ... }
}
var x = new X();
x.k = 42;

​

if you use is isNative=true,  then it would just look like:

// No class is generated, assume X is defined somewhere elsevar x = new X();
x.k = 42;

​
Also thinking them as ES6 classes is useful because then you would see
another problem with your example if you don't use isNative=true:
Because there is a corresponding class, assigning instances from Object
literal is not safe; "{k: 42} instanceof X" is "false" even in javascript.


On Tue, Nov 17, 2015 at 1:49 AM, Ümit Seren  wrote:

> Ok I can confirm that the issue was my fault. After moving everything to a
> JsTyp annotated classes, everything works fine.
>
> I have a last question regarding code size and the use if isNative=true.
> I guess isNative=true is preferred and will make sure that code size stays
> low by not exposing the Java contract to JS.
>
> For example I have a JS library that takes configuration settings as an
> configuration object:
>
> options = { option1:'some string',option2: 24, option3:[],..}
>
> and I want to use JsInterop to write a type safe wrapper for this that is
> only used by GWT/Java code, I would create a class like this (using
> isNative=true instead of just an empty @JsType):
>
> @JsType(isNative=true,namespace=JsPackage.GLOBAL,name="Object")
> public class Options {
>public String option1;
>public int option2;
>...
> }
>
> Thanks in advance
>
>
> P.S:: Great work btw, the new JsInterop is a pleasure to work with.
>
>
> On Monday, November 16, 2015 at 12:26:32 PM UTC+1, Goktug Gokdogan wrote:
>
>
>>
>> On Mon, Nov 16, 2015 at 2:59 AM, Ümit Seren  wrote:
>>
>> Thanks for the info.
>>
>> AFAIK JSNI syntax will go away at some point. I guess I would then rely
>> on a utility class to do that.
>>
>>
>> There is going to be a replacement for JSNI by supplying supplementary js
>> files. So if you have a class with JSNI you can still keep it future
>> compatible but it is a good idea to minimize such classes.
>>
>>
>> One more question:
>> Are there any restrictions regarding @JsProperty fields and Arrays ?
>>
>> somehow following thing dosn't work (it's not set on the object , stays
>> undefined)
>>
>> @JsProperty void setLabels(String[] labels);
>>
>>
>> There is no limitation on this. Most of the time when there is such
>> limitation, compiler gives an error or warning.
>> However there is a bug with respect to non public instance methods;
>> perhaps you are hitting that. Can you provide a full snippet so that I can
>> take a look?
>>
>>
>>
>> On Friday, November 13, 2015 at 7:30:11 PM UTC+1, Goktug Gokdogan wrote:
>>
>>
>>
>> On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  wrote:
>>
>> Is there a way to add dynamic properties to a JsType without relying on
>> JSNI ?
>>
>> With the experimental JSInterop version I had following solution:
>>
>> @JsTypinterface Options {
>>
>>@JsProperty void getSomeProp();
>>
>>@JsProperty String getSomeProp2();
>>@JsProperty void setSomeProp2(String prop);
>>
>> void setSeries(String series, SeriesOptions options);
>> }
>>
>> OptionsImpl implements Options {
>>
>>  
>>
>>  @Override
>>  public final native void setSeries(String series, SeriesOptions 
>> options) /*-{
>>this['series'] = options;
>>  }*-/;
>> }
>>
>> Or generally what’s the best practice regarding generic JS properties ?
>>
>>
>> If you are not implementing an interface with JsProperty, the best way is
>> simply putting a JsProperty field in your class.
>>
>> If you are implementing an interface, you can do what you did here but I
>> would recommend having a separate generic utility class so that you can
>> reuse what you have here in many places. We will probably provide a similar
>> utility class as part of jsinterop at some stage.
>>
>>
>> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan
>> wrote:
>>
>> In native types, the support for static methods are same as the support
>> for static fields; only overlays are supported because we don't modify the
>> native types. Can you give an example that works with static methods and
>> doesn't work with static field but should work as well? What do you mean by
>> "static shared fields"?
>>
>>
>> wrt. overloading: we are not planning to support automatic dispatches per
>> argument count in this version. And btw, method overloading never worked
>> earlier and we recently added support and just for native types.
>>
>> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

Instance methods, static methods and compile time constants can be marked
with JsOverlay. Feel free to send a patch for updating the javadoc if it is
not already there :)

On Tue, Nov 17, 2015 at 4:18 AM, Jens  wrote:

>
> Options options = new Options().init("some string", 24);
>>
>
> Its not directly mentioned in the new spec document but I hope static
> methods are also valid for @JsOverlay? E.g.
>
> Options options = Options.create("some string", 24);
>
> -- 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/4921b1f6-c748-4990-8462-94e452a5b4a1%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%3DyUA1QDRRbKN_rKkEzdzUiwBEO5gJJ%3DfM7hSiBWpjLXmOSdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Ümit Seren]

Seems to be work ;-) 


On Tuesday, November 17, 2015 at 1:18:27 PM UTC+1, Jens wrote:
>
>
> Options options = new Options().init("some string", 24);
>>
>
> Its not directly mentioned in the new spec document but I hope static 
> methods are also valid for @JsOverlay? E.g.
>
> Options options = Options.create("some string", 24); 
>
> -- 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/456693a0-0819-4c27-8f85-282ae1e4aa7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Jens]

> Options options = new Options().init("some string", 24);
>

Its not directly mentioned in the new spec document but I hope static 
methods are also valid for @JsOverlay? E.g.

Options options = Options.create("some string", 24); 

-- 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/4921b1f6-c748-4990-8462-94e452a5b4a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Julien Dramaix]

Your example is correct, this is the way to do. You can also add some logic
to your object (for initialization for instance) by using overlay methods

@JsType(isNative=true,namespace=JsPackage.GLOBAL,name="Object")
public class Options {
  public String option1;
  public int option2;

  @JsOverlay
  public Options init(String option1, int option2) {
this.option1 = option1;
this.option2 = option2;

   return this;
  }
}

Options options = new Options().init("some string", 24);

Julien

On Tue, Nov 17, 2015 at 10:49 AM Ümit Seren  wrote:

> Ok I can confirm that the issue was my fault. After moving everything to a
> JsTyp annotated classes, everything works fine.
>
> I have a last question regarding code size and the use if isNative=true.
> I guess isNative=true is preferred and will make sure that code size stays
> low by not exposing the Java contract to JS.
>
> For example I have a JS library that takes configuration settings as an
> configuration object:
>
> options = { option1:'some string',option2: 24, option3:[],..}
>
> and I want to use JsInterop to write a type safe wrapper for this that is
> only used by GWT/Java code, I would create a class like this (using
> isNative=true instead of just an empty @JsType):
>
> @JsType(isNative=true,namespace=JsPackage.GLOBAL,name="Object")
> public class Options {
>public String option1;
>public int option2;
>...
> }
>
> Thanks in advance
>
>
> P.S:: Great work btw, the new JsInterop is a pleasure to work with.
>
>
> On Monday, November 16, 2015 at 12:26:32 PM UTC+1, Goktug Gokdogan wrote:
>
>
>>
>> On Mon, Nov 16, 2015 at 2:59 AM, Ümit Seren  wrote:
>>
>> Thanks for the info.
>>
>> AFAIK JSNI syntax will go away at some point. I guess I would then rely
>> on a utility class to do that.
>>
>>
>> There is going to be a replacement for JSNI by supplying supplementary js
>> files. So if you have a class with JSNI you can still keep it future
>> compatible but it is a good idea to minimize such classes.
>>
>>
>> One more question:
>> Are there any restrictions regarding @JsProperty fields and Arrays ?
>>
>> somehow following thing dosn't work (it's not set on the object , stays
>> undefined)
>>
>> @JsProperty void setLabels(String[] labels);
>>
>>
>> There is no limitation on this. Most of the time when there is such
>> limitation, compiler gives an error or warning.
>> However there is a bug with respect to non public instance methods;
>> perhaps you are hitting that. Can you provide a full snippet so that I can
>> take a look?
>>
>>
>>
>> On Friday, November 13, 2015 at 7:30:11 PM UTC+1, Goktug Gokdogan wrote:
>>
>>
>>
>> On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  wrote:
>>
>> Is there a way to add dynamic properties to a JsType without relying on
>> JSNI ?
>>
>> With the experimental JSInterop version I had following solution:
>>
>> @JsTypinterface Options {
>>
>>@JsProperty void getSomeProp();
>>
>>@JsProperty String getSomeProp2();
>>@JsProperty void setSomeProp2(String prop);
>>
>> void setSeries(String series, SeriesOptions options);
>> }
>>
>> OptionsImpl implements Options {
>>
>>  
>>
>>  @Override
>>  public final native void setSeries(String series, SeriesOptions 
>> options) /*-{
>>this['series'] = options;
>>  }*-/;
>> }
>>
>> Or generally what’s the best practice regarding generic JS properties ?
>>
>>
>> If you are not implementing an interface with JsProperty, the best way is
>> simply putting a JsProperty field in your class.
>>
>> If you are implementing an interface, you can do what you did here but I
>> would recommend having a separate generic utility class so that you can
>> reuse what you have here in many places. We will probably provide a similar
>> utility class as part of jsinterop at some stage.
>>
>>
>> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan
>> wrote:
>>
>> In native types, the support for static methods are same as the support
>> for static fields; only overlays are supported because we don't modify the
>> native types. Can you give an example that works with static methods and
>> doesn't work with static field but should work as well? What do you mean by
>> "static shared fields"?
>>
>>
>> wrt. overloading: we are not planning to support automatic dispatches per
>> argument count in this version. And btw, method overloading never worked
>> earlier and we recently added support and just for native types.
>>
>> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>>
>> Another issue in the new implementation is that it's not supported any
>> more static shared fields in JsType native interfaces, I think if we
>> support static methods we should support static fields as well, or is there
>> i any reason to prevent it ?.
>>
>> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>> var args sounds pretty good, but some kind of overloading based on the
>> number of para

Re: [gwt-contrib] Re: New JsInterop document

[Ümit Seren]

Ok I can confirm that the issue was my fault. After moving everything to a 
JsTyp annotated classes, everything works fine. 

I have a last question regarding code size and the use if isNative=true.
I guess isNative=true is preferred and will make sure that code size stays 
low by not exposing the Java contract to JS. 

For example I have a JS library that takes configuration settings as an 
configuration object: 

options = { option1:'some string',option2: 24, option3:[],..}

and I want to use JsInterop to write a type safe wrapper for this that is 
only used by GWT/Java code, I would create a class like this (using 
isNative=true instead of just an empty @JsType): 

@JsType(isNative=true,namespace=JsPackage.GLOBAL,name="Object")
public class Options {
   public String option1;
   public int option2;
   ...
}

Thanks in advance


P.S:: Great work btw, the new JsInterop is a pleasure to work with. 


On Monday, November 16, 2015 at 12:26:32 PM UTC+1, Goktug Gokdogan wrote:


>
> On Mon, Nov 16, 2015 at 2:59 AM, Ümit Seren  > wrote:
>
> Thanks for the info. 
>
> AFAIK JSNI syntax will go away at some point. I guess I would then rely on 
> a utility class to do that. 
>
>
> There is going to be a replacement for JSNI by supplying supplementary js 
> files. So if you have a class with JSNI you can still keep it future 
> compatible but it is a good idea to minimize such classes.
>  
>
> One more question: 
> Are there any restrictions regarding @JsProperty fields and Arrays ? 
>
> somehow following thing dosn't work (it's not set on the object , stays 
> undefined) 
>
> @JsProperty void setLabels(String[] labels);
>
>
> There is no limitation on this. Most of the time when there is such 
> limitation, compiler gives an error or warning.
> However there is a bug with respect to non public instance methods; 
> perhaps you are hitting that. Can you provide a full snippet so that I can 
> take a look?
>  
>
>
> On Friday, November 13, 2015 at 7:30:11 PM UTC+1, Goktug Gokdogan wrote:
>
>
>
> On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  wrote:
>
> Is there a way to add dynamic properties to a JsType without relying on 
> JSNI ? 
>
> With the experimental JSInterop version I had following solution:
>
> @JsTypinterface Options {
>
>@JsProperty void getSomeProp();
>
>@JsProperty String getSomeProp2();
>@JsProperty void setSomeProp2(String prop);
>
> void setSeries(String series, SeriesOptions options);
> }
>
> OptionsImpl implements Options {
>
>  
>
>  @Override
>  public final native void setSeries(String series, SeriesOptions options) 
> /*-{
>this['series'] = options;
>  }*-/;
> }
>
> Or generally what’s the best practice regarding generic JS properties ?
>
>
> If you are not implementing an interface with JsProperty, the best way is 
> simply putting a JsProperty field in your class.
>
> If you are implementing an interface, you can do what you did here but I 
> would recommend having a separate generic utility class so that you can 
> reuse what you have here in many places. We will probably provide a similar 
> utility class as part of jsinterop at some stage.
>  
>
> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan wrote:
>
> In native types, the support for static methods are same as the support 
> for static fields; only overlays are supported because we don't modify the 
> native types. Can you give an example that works with static methods and 
> doesn't work with static field but should work as well? What do you mean by 
> "static shared fields"?
>
>
> wrt. overloading: we are not planning to support automatic dispatches per 
> argument count in this version. And btw, method overloading never worked 
> earlier and we recently added support and just for native types.
>
> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino  > wrote:
>
>
> Another issue in the new implementation is that it's not supported any 
> more static shared fields in JsType native interfaces, I think if we 
> support static methods we should support static fields as well, or is there 
> i any reason to prevent it ?.
>
> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino  > wrote:
>
> var args sounds pretty good, but some kind of overloading based on the 
> number of parameters like we had in gwt-exporter should cover many use 
> cases, compiler could give an error (like it does now) when it sees two 
> methods with the same-number-of-parameters signature.
>
>
>
> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT 
> Contributors  wrote:
>
> No plan to support through Java implementors, although there are plans to 
> support varargs which would let you accomplish something similar.
> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino"  wrote:
>
> I see, it works, thanks.
>
> Any plan to work as well with gwt exported classes ?
>
> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix  
> wrote:
>
> Method overloading works in native JsType JsType(isNative=

Re: [gwt-contrib] Re: New JsInterop document

[Ümit Seren]

Ok, I think the issue regarding setLabels(String[] labels) is my fault. 

Previously I had an interface that was annotated with @JsType and a class 
that was implementing it and when I switched to the latest JS_RC JsInterop 
I re-created the implementing class from scratch but with empty function 
bodies (don’t know why I did that): 

@JsType
public interface Options {

  @JsProperty void setLabels(String[] labels);
}

class OptionsImpl implements Options {

  @Override
  public void setLabels(String[] labels) { 
  }
}

I guess that’s the reason why labels wasn’t set, I probably need to add a 
field and assign it in the OptionsImpl class. 

But I decided to drop the interface anyways and just move everything into 
the OptionsImpl class (easier to maintain).

Sorry for the inconvenience 

On Monday, November 16, 2015 at 12:26:32 PM UTC+1, Goktug Gokdogan wrote:


>
> On Mon, Nov 16, 2015 at 2:59 AM, Ümit Seren  > wrote:
>
> Thanks for the info. 
>
> AFAIK JSNI syntax will go away at some point. I guess I would then rely on 
> a utility class to do that. 
>
>
> There is going to be a replacement for JSNI by supplying supplementary js 
> files. So if you have a class with JSNI you can still keep it future 
> compatible but it is a good idea to minimize such classes.
>  
>
> One more question: 
> Are there any restrictions regarding @JsProperty fields and Arrays ? 
>
> somehow following thing dosn't work (it's not set on the object , stays 
> undefined) 
>
> @JsProperty void setLabels(String[] labels);
>
>
> There is no limitation on this. Most of the time when there is such 
> limitation, compiler gives an error or warning.
> However there is a bug with respect to non public instance methods; 
> perhaps you are hitting that. Can you provide a full snippet so that I can 
> take a look?
>  
>
>
> On Friday, November 13, 2015 at 7:30:11 PM UTC+1, Goktug Gokdogan wrote:
>
>
>
> On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  wrote:
>
> Is there a way to add dynamic properties to a JsType without relying on 
> JSNI ? 
>
> With the experimental JSInterop version I had following solution:
>
> @JsTypinterface Options {
>
>@JsProperty void getSomeProp();
>
>@JsProperty String getSomeProp2();
>@JsProperty void setSomeProp2(String prop);
>
> void setSeries(String series, SeriesOptions options);
> }
>
> OptionsImpl implements Options {
>
>  
>
>  @Override
>  public final native void setSeries(String series, SeriesOptions options) 
> /*-{
>this['series'] = options;
>  }*-/;
> }
>
> Or generally what’s the best practice regarding generic JS properties ?
>
>
> If you are not implementing an interface with JsProperty, the best way is 
> simply putting a JsProperty field in your class.
>
> If you are implementing an interface, you can do what you did here but I 
> would recommend having a separate generic utility class so that you can 
> reuse what you have here in many places. We will probably provide a similar 
> utility class as part of jsinterop at some stage.
>  
>
> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan wrote:
>
> In native types, the support for static methods are same as the support 
> for static fields; only overlays are supported because we don't modify the 
> native types. Can you give an example that works with static methods and 
> doesn't work with static field but should work as well? What do you mean by 
> "static shared fields"?
>
>
> wrt. overloading: we are not planning to support automatic dispatches per 
> argument count in this version. And btw, method overloading never worked 
> earlier and we recently added support and just for native types.
>
> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino  > wrote:
>
>
> Another issue in the new implementation is that it's not supported any 
> more static shared fields in JsType native interfaces, I think if we 
> support static methods we should support static fields as well, or is there 
> i any reason to prevent it ?.
>
> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino  > wrote:
>
> var args sounds pretty good, but some kind of overloading based on the 
> number of parameters like we had in gwt-exporter should cover many use 
> cases, compiler could give an error (like it does now) when it sees two 
> methods with the same-number-of-parameters signature.
>
>
>
> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT 
> Contributors  wrote:
>
> No plan to support through Java implementors, although there are plans to 
> support varargs which would let you accomplish something similar.
> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino"  wrote:
>
> I see, it works, thanks.
>
> Any plan to work as well with gwt exported classes ?
>
> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix  
> wrote:
>
> Method overloading works in native JsType JsType(isNative=true)
>
> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino  
> wrote:
>
> Seems that method overloading is no

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

On Mon, Nov 16, 2015 at 2:59 AM, Ümit Seren  wrote:

> Thanks for the info.
>
> AFAIK JSNI syntax will go away at some point. I guess I would then rely on
> a utility class to do that.
>
>
There is going to be a replacement for JSNI by supplying supplementary js
files. So if you have a class with JSNI you can still keep it future
compatible but it is a good idea to minimize such classes.


> One more question:
> Are there any restrictions regarding @JsProperty fields and Arrays ?
>
> somehow following thing dosn't work (it's not set on the object , stays
> undefined)
>
> @JsProperty void setLabels(String[] labels);
>
>
There is no limitation on this. Most of the time when there is such
limitation, compiler gives an error or warning.
However there is a bug with respect to non public instance methods; perhaps
you are hitting that. Can you provide a full snippet so that I can take a
look?


>
> On Friday, November 13, 2015 at 7:30:11 PM UTC+1, Goktug Gokdogan wrote:
>
>>
>>
>> On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  wrote:
>>
>>> Is there a way to add dynamic properties to a JsType without relying on
>>> JSNI ?
>>>
>>> With the experimental JSInterop version I had following solution:
>>>
>>> @JsTypinterface Options {
>>>
>>>@JsProperty void getSomeProp();
>>>
>>>@JsProperty String getSomeProp2();
>>>@JsProperty void setSomeProp2(String prop);
>>>
>>> void setSeries(String series, SeriesOptions options);
>>> }
>>>
>>> OptionsImpl implements Options {
>>>
>>>  
>>>
>>>  @Override
>>>  public final native void setSeries(String series, SeriesOptions 
>>> options) /*-{
>>>this['series'] = options;
>>>  }*-/;
>>> }
>>>
>>> Or generally what’s the best practice regarding generic JS properties ?
>>>
>>
>> If you are not implementing an interface with JsProperty, the best way is
>> simply putting a JsProperty field in your class.
>>
>> If you are implementing an interface, you can do what you did here but I
>> would recommend having a separate generic utility class so that you can
>> reuse what you have here in many places. We will probably provide a similar
>> utility class as part of jsinterop at some stage.
>>
>>
>>> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan
>>> wrote:
>>>
>>> In native types, the support for static methods are same as the support
 for static fields; only overlays are supported because we don't modify the
 native types. Can you give an example that works with static methods and
 doesn't work with static field but should work as well? What do you mean by
 "static shared fields"?


 wrt. overloading: we are not planning to support automatic dispatches
 per argument count in this version. And btw, method overloading never
 worked earlier and we recently added support and just for native types.

 On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino <
 man...@apache.org> wrote:

>
> Another issue in the new implementation is that it's not supported any
> more static shared fields in JsType native interfaces, I think if we
> support static methods we should support static fields as well, or is 
> there
> i any reason to prevent it ?.
>
> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino <
> man...@apache.org> wrote:
>
>> var args sounds pretty good, but some kind of overloading based on
>> the number of parameters like we had in gwt-exporter should cover many 
>> use
>> cases, compiler could give an error (like it does now) when it sees two
>> methods with the same-number-of-parameters signature.
>>
>>
>>
>> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT
>> Contributors 
>> wrote:
>>
>>> No plan to support through Java implementors, although there are
>>> plans to support varargs which would let you accomplish something 
>>> similar.
>>> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" 
>>> wrote:
>>>
 I see, it works, thanks.

 Any plan to work as well with gwt exported classes ?

 On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix <
 julien@gmail.com> wrote:

> Method overloading works in native JsType JsType(isNative=true)
>
> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
> man...@apache.org> wrote:
>
>> Seems that method overloading is not working anymore with JS_RC
>> mode, it was working in JS mode though:
>>
>> Example:
>>
>>boolean validate()
>>boolean validate(String foo)
>>
>> Is it a feature not implemented yet, or it is not in the
>> specification?
>>
>> Thanks
>> - Manolo
>>
>>
>> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi <
>> csri...@gmail.com> wrote:
>>
>>>

Re: [gwt-contrib] Re: New JsInterop document

[Ümit Seren]

Thanks for the info. 

AFAIK JSNI syntax will go away at some point. I guess I would then rely on 
a utility class to do that. 

One more question: 
Are there any restrictions regarding @JsProperty fields and Arrays ? 

somehow following thing dosn't work (it's not set on the object , stays 
undefined) 

@JsProperty void setLabels(String[] labels);


On Friday, November 13, 2015 at 7:30:11 PM UTC+1, Goktug Gokdogan wrote:
>
>
>
> On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  > wrote:
>
>> Is there a way to add dynamic properties to a JsType without relying on 
>> JSNI ? 
>>
>> With the experimental JSInterop version I had following solution:
>>
>> @JsTypinterface Options {
>>
>>@JsProperty void getSomeProp();
>>
>>@JsProperty String getSomeProp2();
>>@JsProperty void setSomeProp2(String prop);
>>
>> void setSeries(String series, SeriesOptions options);
>> }
>>
>> OptionsImpl implements Options {
>>
>>  
>>
>>  @Override
>>  public final native void setSeries(String series, SeriesOptions 
>> options) /*-{
>>this['series'] = options;
>>  }*-/;
>> }
>>
>> Or generally what’s the best practice regarding generic JS properties ?
>>
>
> If you are not implementing an interface with JsProperty, the best way is 
> simply putting a JsProperty field in your class.
>
> If you are implementing an interface, you can do what you did here but I 
> would recommend having a separate generic utility class so that you can 
> reuse what you have here in many places. We will probably provide a similar 
> utility class as part of jsinterop at some stage.
>  
>
>> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan 
>> wrote:
>>
>> In native types, the support for static methods are same as the support 
>>> for static fields; only overlays are supported because we don't modify the 
>>> native types. Can you give an example that works with static methods and 
>>> doesn't work with static field but should work as well? What do you mean by 
>>> "static shared fields"?
>>>
>>>
>>> wrt. overloading: we are not planning to support automatic dispatches 
>>> per argument count in this version. And btw, method overloading never 
>>> worked earlier and we recently added support and just for native types.
>>>
>>> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>

 Another issue in the new implementation is that it's not supported any 
 more static shared fields in JsType native interfaces, I think if we 
 support static methods we should support static fields as well, or is 
 there 
 i any reason to prevent it ?.

 On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino <
 man...@apache.org> wrote:

> var args sounds pretty good, but some kind of overloading based on the 
> number of parameters like we had in gwt-exporter should cover many use 
> cases, compiler could give an error (like it does now) when it sees two 
> methods with the same-number-of-parameters signature.
>
>
>
> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT 
> Contributors  wrote:
>
>> No plan to support through Java implementors, although there are 
>> plans to support varargs which would let you accomplish something 
>> similar.
>> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino"  
>> wrote:
>>
>>> I see, it works, thanks.
>>>
>>> Any plan to work as well with gwt exported classes ?
>>>
>>> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix <
>>> julien@gmail.com> wrote:
>>>
 Method overloading works in native JsType JsType(isNative=true)

 On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
 man...@apache.org> wrote:

> Seems that method overloading is not working anymore with JS_RC 
> mode, it was working in JS mode though:
>
> Example:
>
>boolean validate()
>boolean validate(String foo)
>
> Is it a feature not implemented yet, or it is not in the 
> specification?
>
> Thanks
> - Manolo
>
>
> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi <
> csri...@gmail.com> wrote:
>
>> Thanks Julien!!!
>>
>> This work fine!!
>>
>> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug 
>> Gokdogan escribió:
>>>
>>> As we are getting close to 2.8 release I wrote a new document 
>>> that is concentrating on jsinterop features to be released in 2.8:
>>>
>>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>>
>>> Please share your feedback.
>>>
>>> Thanks,
>>>
>>> Goktug
>>>
>> -- 
>> You received this message because you are subscribed to t

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

I think there was a misunderstanding. You mentioned "if we support static
methods we should support static fields as well" and I said both should NOT
work without JsOverlay. It seems like your examples correctly gives an
error for both static method and the static field because they don't have
the JsOverlay.
Any method or field addition to a native type (anything doesn't already
exist in the underlying native type) requires you to overlay them hence you
need to put @JsOverlay.

Also note that your example uses JsType without prototype on old style
annotations but uses JsType with isNative on JS_RC annotations. There are
not equivalent.  If you remove the isNative, it should work same. Only
difference is, you can get away with compile time constants in old style
annotations as they don't need clinit.

As a clarification; you need to use native JsType classes when there is a
corresponding natively provided JavaScript type and use native JsType
interfaces when the corresponding native type doesn't matter or unknown.


On Sat, Nov 14, 2015 at 12:46 AM, Manuel Carrasco Moñino 
wrote:

> Goktug, this is an example perfectly working with jsInteropMode=JS but not
> working with JS_RC :
>   (Errors : Native JsType field 'String MyComponent.TAG' cannot have
> initializer &  Native JsType method 'String MyComponent.getTagName()'
> should be native or abstract)
>
> @com.google.gwt.core.client.js.JsType
>
> @jsinterop.annotations.JsType(isNative=true)
>
> public interface MyComponent {
>
>  public static String TAG = "my-component";
>
>  public static String getTagName() {
>
>return TAG;
>
>  }
>
>  @jsinterop.annotations.JsProperty
>
>  @com.google.gwt.core.client.js.JsProperty
>
>  public String getFoo();
>
>  @jsinterop.annotations.JsProperty
>
>  @com.google.gwt.core.client.js.JsProperty
>
>  public void setFoo(String foo);
>
> }
>
>
> public void onModuleLoad() {
>
>  assert MyComponent.getTagName() == MyComponent.TAG;
>
>  Element elem = Document.get().createElement(MyComponent.TAG);
>
>  Document.get().getBody().appendChild(elem);
>
>  MyComponent comp = (MyComponent) elem;
>
>  comp.setFoo("bar");
>
> }
>
>
>
>
>
> On Wed, Nov 11, 2015 at 6:25 AM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> In native types, the support for static methods are same as the support
>> for static fields; only overlays are supported because we don't modify the
>> native types. Can you give an example that works with static methods and
>> doesn't work with static field but should work as well? What do you mean by
>> "static shared fields"?
>>
>>
>> wrt. overloading: we are not planning to support automatic dispatches per
>> argument count in this version. And btw, method overloading never worked
>> earlier and we recently added support and just for native types.
>>
>> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>>>
>>> Another issue in the new implementation is that it's not supported any
>>> more static shared fields in JsType native interfaces, I think if we
>>> support static methods we should support static fields as well, or is there
>>> i any reason to prevent it ?.
>>>
>>> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>
 var args sounds pretty good, but some kind of overloading based on the
 number of parameters like we had in gwt-exporter should cover many use
 cases, compiler could give an error (like it does now) when it sees two
 methods with the same-number-of-parameters signature.



 On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT
 Contributors  wrote:

> No plan to support through Java implementors, although there are plans
> to support varargs which would let you accomplish something similar.
> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" 
> wrote:
>
>> I see, it works, thanks.
>>
>> Any plan to work as well with gwt exported classes ?
>>
>> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix <
>> julien.dram...@gmail.com> wrote:
>>
>>> Method overloading works in native JsType JsType(isNative=true)
>>>
>>> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>
 Seems that method overloading is not working anymore with JS_RC
 mode, it was working in JS mode though:

 Example:

boolean validate()
boolean validate(String foo)

 Is it a feature not implemented yet, or it is not in the
 specification?

 Thanks
 - Manolo


 On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi <
 csrina...@gmail.com> wrote:

> Thanks Julien!!!
>
> This work fine!!
>
> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug
> Gokdogan escri

Re: [gwt-contrib] Re: New JsInterop document

[Manuel Carrasco Moñino]

Goktug, this is an example perfectly working with jsInteropMode=JS but not
working with JS_RC :
  (Errors : Native JsType field 'String MyComponent.TAG' cannot have
initializer &  Native JsType method 'String MyComponent.getTagName()'
should be native or abstract)

@com.google.gwt.core.client.js.JsType

@jsinterop.annotations.JsType(isNative=true)

public interface MyComponent {

 public static String TAG = "my-component";

 public static String getTagName() {

   return TAG;

 }

 @jsinterop.annotations.JsProperty

 @com.google.gwt.core.client.js.JsProperty

 public String getFoo();

 @jsinterop.annotations.JsProperty

 @com.google.gwt.core.client.js.JsProperty

 public void setFoo(String foo);

}


public void onModuleLoad() {

 assert MyComponent.getTagName() == MyComponent.TAG;

 Element elem = Document.get().createElement(MyComponent.TAG);

 Document.get().getBody().appendChild(elem);

 MyComponent comp = (MyComponent) elem;

 comp.setFoo("bar");

}





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

> In native types, the support for static methods are same as the support
> for static fields; only overlays are supported because we don't modify the
> native types. Can you give an example that works with static methods and
> doesn't work with static field but should work as well? What do you mean by
> "static shared fields"?
>
>
> wrt. overloading: we are not planning to support automatic dispatches per
> argument count in this version. And btw, method overloading never worked
> earlier and we recently added support and just for native types.
>
> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino  > wrote:
>
>>
>> Another issue in the new implementation is that it's not supported any
>> more static shared fields in JsType native interfaces, I think if we
>> support static methods we should support static fields as well, or is there
>> i any reason to prevent it ?.
>>
>> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>>> var args sounds pretty good, but some kind of overloading based on the
>>> number of parameters like we had in gwt-exporter should cover many use
>>> cases, compiler could give an error (like it does now) when it sees two
>>> methods with the same-number-of-parameters signature.
>>>
>>>
>>>
>>> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT
>>> Contributors  wrote:
>>>
 No plan to support through Java implementors, although there are plans
 to support varargs which would let you accomplish something similar.
 On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" 
 wrote:

> I see, it works, thanks.
>
> Any plan to work as well with gwt exported classes ?
>
> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix <
> julien.dram...@gmail.com> wrote:
>
>> Method overloading works in native JsType JsType(isNative=true)
>>
>> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>>> Seems that method overloading is not working anymore with JS_RC
>>> mode, it was working in JS mode though:
>>>
>>> Example:
>>>
>>>boolean validate()
>>>boolean validate(String foo)
>>>
>>> Is it a feature not implemented yet, or it is not in the
>>> specification?
>>>
>>> Thanks
>>> - Manolo
>>>
>>>
>>> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi <
>>> csrina...@gmail.com> wrote:
>>>
 Thanks Julien!!!

 This work fine!!

 El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
 escribió:
>
> As we are getting close to 2.8 release I wrote a new document that
> is concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>
 --
 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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.
>>> 

Re: [gwt-contrib] Re: New JsInterop document

['Ray Cromwell' via GWT Contributors]

I think you might be able to get away with Async functions something like
this:

@JsFunction
interface AsyncFunction {
   T execute();
}

public class Foo {
   Promise fetchJson() {
   return Async.await(Xhr.fetch("/someJson")); // returns a
Promise
   }
}

public class Async {
   @MustBeInlined
   public static native  Promise await(Promise x) /*-{ yield x;
}-*/;
   public static native void makeFooAsync(Foo f) /*-{
 var old = f.@Foo::fetchJson;
 f.@Foo::fetchJson = function*() { return old.apply(f, arguments); }
   }-*/;
}

But I'm not sure. I prototyped a Linker approach to doing this by running
the output JS through the linker, finding all functions declared as @Async,
and adding 'async' keyword in front of them, then invoking BabelJS at the
end. I wrote about it in a G+ post and it works.

ES7 is quite a ways off so I'd probably suggest that for J2Cl this has to
be done with some kind of similar genrule to post process the JS.

It doesn't seem a stretch to imagine that Java annotations could be
harnessed to output decorators. @JsProperty is already a kind of decorator.

Personally, I think Symbols, Iterators, and Generators should be part of a
future JsInterop revision, regardless of whether Java has first class
support for them, there are always annotated or library based approaches
that can be used.


On Fri, Nov 13, 2015 at 1:51 PM, 'John Stalcup' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Generally speaking J2CL seeks to support Java language features and in the
> process of doing so make use of modern ES6 features. When it comes to the
> separate topic of making advanced ES6 features (that don't exist in the
> Java language) available to J2CL users the path for that is via the
> JsInterop spec.
>
> To be specific:
>
> - J2CL currently outputs Closure goog.module()s instead of ES6 modules
> because no browser yet supports ES6 modules and we like having our output
> immediately runnable in the browser without a ES6to5 downsampling. When
> browsers support ES6 modules we are likely to switch.
> - When/if the Java language provides Decorators/Generators/Async
> functions we will transpile them
> - The JsInterop spec does not currently provide sugar for 
> Decorators/Generators/Async
> functions but it might in a future revision
> - You can already take advantage of Generators and Async functions (but
> probably not Decorators) by using JsInterop to expose a JS library to Java
> where that JS library exposes utility functions for Generators and Async
> functions
>
>
> On Fri, Nov 13, 2015 at 1:27 PM, Paul Stockley 
> wrote:
>
>> Do you plan on supporting these features in j2cl in the future?
>>
>> On Friday, November 13, 2015 at 4:23:21 PM UTC-5, Ray Cromwell wrote:
>>>
>>>
>>> You could probably support Modules via a GWT linker. Generators and
>>> Async functions could be done by a GWT Generator/Linker combo + BabelJS.
>>> There's no real plans to support ES6 in GWT, but you could arrange enough
>>> hacks with Generator/Linker/Library stuff to make GWT 2.x stuff consumable
>>> from ES6 code.
>>>
>>> On Fri, Nov 13, 2015 at 1:21 PM, Paul Stockley 
>>> wrote:
>>>
 A number of the new frameworks (Angular 2, Aurelia)  are planning on
 using ES6 and ES7 features such as Modules, Decorators, Generators and
 Async functions etc. Are there plans to support these on the 2.x code base
 or would these only be supported by j2cl in the future?

 On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>
> As we are getting close to 2.8 release I wrote a new document that is
> concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>
 --
 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/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%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/b5adb853-08d2-42b1-a69a-fccc2d81004d%40goo

Re: [gwt-contrib] Re: New JsInterop document

['John Stalcup' via GWT Contributors]

Generally speaking J2CL seeks to support Java language features and in the
process of doing so make use of modern ES6 features. When it comes to the
separate topic of making advanced ES6 features (that don't exist in the
Java language) available to J2CL users the path for that is via the
JsInterop spec.

To be specific:

- J2CL currently outputs Closure goog.module()s instead of ES6 modules
because no browser yet supports ES6 modules and we like having our output
immediately runnable in the browser without a ES6to5 downsampling. When
browsers support ES6 modules we are likely to switch.
- When/if the Java language provides Decorators/Generators/Async functions
we will transpile them
- The JsInterop spec does not currently provide sugar for
Decorators/Generators/Async
functions but it might in a future revision
- You can already take advantage of Generators and Async functions (but
probably not Decorators) by using JsInterop to expose a JS library to Java
where that JS library exposes utility functions for Generators and Async
functions


On Fri, Nov 13, 2015 at 1:27 PM, Paul Stockley  wrote:

> Do you plan on supporting these features in j2cl in the future?
>
> On Friday, November 13, 2015 at 4:23:21 PM UTC-5, Ray Cromwell wrote:
>>
>>
>> You could probably support Modules via a GWT linker. Generators and Async
>> functions could be done by a GWT Generator/Linker combo + BabelJS.  There's
>> no real plans to support ES6 in GWT, but you could arrange enough hacks
>> with Generator/Linker/Library stuff to make GWT 2.x stuff consumable from
>> ES6 code.
>>
>> On Fri, Nov 13, 2015 at 1:21 PM, Paul Stockley 
>> wrote:
>>
>>> A number of the new frameworks (Angular 2, Aurelia)  are planning on
>>> using ES6 and ES7 features such as Modules, Decorators, Generators and
>>> Async functions etc. Are there plans to support these on the 2.x code base
>>> or would these only be supported by j2cl in the future?
>>>
>>> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:

 As we are getting close to 2.8 release I wrote a new document that is
 concentrating on jsinterop features to be released in 2.8:

 https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#

 Please share your feedback.

 Thanks,

 Goktug

>>> --
>>> 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/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%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/b5adb853-08d2-42b1-a69a-fccc2d81004d%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/CAFw3gJ-%3DWHGsq--dO7jj825U64iqj_ZNCjU9_P8-hP3T4MYFOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Paul Stockley]

Do you plan on supporting these features in j2cl in the future?

On Friday, November 13, 2015 at 4:23:21 PM UTC-5, Ray Cromwell wrote:
>
>
> You could probably support Modules via a GWT linker. Generators and Async 
> functions could be done by a GWT Generator/Linker combo + BabelJS.  There's 
> no real plans to support ES6 in GWT, but you could arrange enough hacks 
> with Generator/Linker/Library stuff to make GWT 2.x stuff consumable from 
> ES6 code.
>
> On Fri, Nov 13, 2015 at 1:21 PM, Paul Stockley  > wrote:
>
>> A number of the new frameworks (Angular 2, Aurelia)  are planning on 
>> using ES6 and ES7 features such as Modules, Decorators, Generators and 
>> Async functions etc. Are there plans to support these on the 2.x code base 
>> or would these only be supported by j2cl in the future? 
>>
>> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>>>
>>> As we are getting close to 2.8 release I wrote a new document that is 
>>> concentrating on jsinterop features to be released in 2.8:
>>>
>>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>>
>>> Please share your feedback.
>>>
>>> Thanks,
>>>
>>> Goktug
>>>
>> -- 
>> 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/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%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/b5adb853-08d2-42b1-a69a-fccc2d81004d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

['Ray Cromwell' via GWT Contributors]

You could probably support Modules via a GWT linker. Generators and Async
functions could be done by a GWT Generator/Linker combo + BabelJS.  There's
no real plans to support ES6 in GWT, but you could arrange enough hacks
with Generator/Linker/Library stuff to make GWT 2.x stuff consumable from
ES6 code.

On Fri, Nov 13, 2015 at 1:21 PM, Paul Stockley  wrote:

> A number of the new frameworks (Angular 2, Aurelia)  are planning on using
> ES6 and ES7 features such as Modules, Decorators, Generators and Async
> functions etc. Are there plans to support these on the 2.x code base or
> would these only be supported by j2cl in the future?
>
> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>>
>> As we are getting close to 2.8 release I wrote a new document that is
>> concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> 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/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%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/CAPVRV7frDE8%3DZ2iEhNnkbp9wwNNSNADKL1u%2BoLRrHHBFwZOYbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: New JsInterop document

[Paul Stockley]

A number of the new frameworks (Angular 2, Aurelia)  are planning on using 
ES6 and ES7 features such as Modules, Decorators, Generators and Async 
functions etc. Are there plans to support these on the 2.x code base or 
would these only be supported by j2cl in the future? 

On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>
> As we are getting close to 2.8 release I wrote a new document that is 
> concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>

-- 
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/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

On Fri, Nov 13, 2015 at 6:28 AM, Ümit Seren  wrote:

> Is there a way to add dynamic properties to a JsType without relying on
> JSNI ?
>
> With the experimental JSInterop version I had following solution:
>
> @JsTypinterface Options {
>
>@JsProperty void getSomeProp();
>
>@JsProperty String getSomeProp2();
>@JsProperty void setSomeProp2(String prop);
>
> void setSeries(String series, SeriesOptions options);
> }
>
> OptionsImpl implements Options {
>
>  
>
>  @Override
>  public final native void setSeries(String series, SeriesOptions options) 
> /*-{
>this['series'] = options;
>  }*-/;
> }
>
> Or generally what’s the best practice regarding generic JS properties ?
>

If you are not implementing an interface with JsProperty, the best way is
simply putting a JsProperty field in your class.

If you are implementing an interface, you can do what you did here but I
would recommend having a separate generic utility class so that you can
reuse what you have here in many places. We will probably provide a similar
utility class as part of jsinterop at some stage.


> On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan wrote:
>
> In native types, the support for static methods are same as the support
>> for static fields; only overlays are supported because we don't modify the
>> native types. Can you give an example that works with static methods and
>> doesn't work with static field but should work as well? What do you mean by
>> "static shared fields"?
>>
>>
>> wrt. overloading: we are not planning to support automatic dispatches per
>> argument count in this version. And btw, method overloading never worked
>> earlier and we recently added support and just for native types.
>>
>> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>>>
>>> Another issue in the new implementation is that it's not supported any
>>> more static shared fields in JsType native interfaces, I think if we
>>> support static methods we should support static fields as well, or is there
>>> i any reason to prevent it ?.
>>>
>>> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>
 var args sounds pretty good, but some kind of overloading based on the
 number of parameters like we had in gwt-exporter should cover many use
 cases, compiler could give an error (like it does now) when it sees two
 methods with the same-number-of-parameters signature.



 On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT
 Contributors  wrote:

> No plan to support through Java implementors, although there are plans
> to support varargs which would let you accomplish something similar.
> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" 
> wrote:
>
>> I see, it works, thanks.
>>
>> Any plan to work as well with gwt exported classes ?
>>
>> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix > > wrote:
>>
>>> Method overloading works in native JsType JsType(isNative=true)
>>>
>>> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>
 Seems that method overloading is not working anymore with JS_RC
 mode, it was working in JS mode though:

 Example:

boolean validate()
boolean validate(String foo)

 Is it a feature not implemented yet, or it is not in the
 specification?

 Thanks
 - Manolo


 On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi >>> > wrote:

> Thanks Julien!!!
>
> This work fine!!
>
> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug
> Gokdogan escribió:
>>
>> As we are getting close to 2.8 release I wrote a new document
>> that is concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.co

Re: [gwt-contrib] Re: New JsInterop document

[Ümit Seren]

Is there a way to add dynamic properties to a JsType without relying on 
JSNI ? 

With the experimental JSInterop version I had following solution:

@JsTypinterface Options {

   @JsProperty void getSomeProp();

   @JsProperty String getSomeProp2();
   @JsProperty void setSomeProp2(String prop);

void setSeries(String series, SeriesOptions options);
}

OptionsImpl implements Options {

 

 @Override
 public final native void setSeries(String series, SeriesOptions options) 
/*-{
   this['series'] = options;
 }*-/;
}

Or generally what’s the best practice regarding generic JS properties ? 

On Wednesday, November 11, 2015 at 6:26:09 AM UTC+1, Goktug Gokdogan wrote:

In native types, the support for static methods are same as the support for 
> static fields; only overlays are supported because we don't modify the 
> native types. Can you give an example that works with static methods and 
> doesn't work with static field but should work as well? What do you mean by 
> "static shared fields"?
>
>
> wrt. overloading: we are not planning to support automatic dispatches per 
> argument count in this version. And btw, method overloading never worked 
> earlier and we recently added support and just for native types.
>
> On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino  > wrote:
>
>>
>> Another issue in the new implementation is that it's not supported any 
>> more static shared fields in JsType native interfaces, I think if we 
>> support static methods we should support static fields as well, or is there 
>> i any reason to prevent it ?.
>>
>> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino <
>> man...@apache.org > wrote:
>>
>>> var args sounds pretty good, but some kind of overloading based on the 
>>> number of parameters like we had in gwt-exporter should cover many use 
>>> cases, compiler could give an error (like it does now) when it sees two 
>>> methods with the same-number-of-parameters signature.
>>>
>>>
>>>
>>> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT 
>>> Contributors >> > wrote:
>>>
 No plan to support through Java implementors, although there are plans 
 to support varargs which would let you accomplish something similar.
 On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" >>> > wrote:

> I see, it works, thanks.
>
> Any plan to work as well with gwt exported classes ?
>
> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix  > wrote:
>
>> Method overloading works in native JsType JsType(isNative=true)
>>
>> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
>> man...@apache.org > wrote:
>>
>>> Seems that method overloading is not working anymore with JS_RC 
>>> mode, it was working in JS mode though:
>>>
>>> Example:
>>>
>>>boolean validate()
>>>boolean validate(String foo)
>>>
>>> Is it a feature not implemented yet, or it is not in the 
>>> specification?
>>>
>>> Thanks
>>> - Manolo
>>>
>>>
>>> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi >> > wrote:
>>>
 Thanks Julien!!!

 This work fine!!

 El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan 
 escribió:
>
> As we are getting close to 2.8 release I wrote a new document that 
> is concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>
 -- 
 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.com
>>>  
>>> 

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

In native types, the support for static methods are same as the support for
static fields; only overlays are supported because we don't modify the
native types. Can you give an example that works with static methods and
doesn't work with static field but should work as well? What do you mean by
"static shared fields"?


wrt. overloading: we are not planning to support automatic dispatches per
argument count in this version. And btw, method overloading never worked
earlier and we recently added support and just for native types.

On Tue, Nov 10, 2015 at 4:19 PM, Manuel Carrasco Moñino 
wrote:

>
> Another issue in the new implementation is that it's not supported any
> more static shared fields in JsType native interfaces, I think if we
> support static methods we should support static fields as well, or is there
> i any reason to prevent it ?.
>
> On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino  > wrote:
>
>> var args sounds pretty good, but some kind of overloading based on the
>> number of parameters like we had in gwt-exporter should cover many use
>> cases, compiler could give an error (like it does now) when it sees two
>> methods with the same-number-of-parameters signature.
>>
>>
>>
>> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>>
>>> No plan to support through Java implementors, although there are plans
>>> to support varargs which would let you accomplish something similar.
>>> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" 
>>> wrote:
>>>
 I see, it works, thanks.

 Any plan to work as well with gwt exported classes ?

 On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix <
 julien.dram...@gmail.com> wrote:

> Method overloading works in native JsType JsType(isNative=true)
>
> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
> man...@apache.org> wrote:
>
>> Seems that method overloading is not working anymore with JS_RC mode,
>> it was working in JS mode though:
>>
>> Example:
>>
>>boolean validate()
>>boolean validate(String foo)
>>
>> Is it a feature not implemented yet, or it is not in the
>> specification?
>>
>> Thanks
>> - Manolo
>>
>>
>> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi > > wrote:
>>
>>> Thanks Julien!!!
>>>
>>> This work fine!!
>>>
>>> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
>>> escribió:

 As we are getting close to 2.8 release I wrote a new document that
 is concentrating on jsinterop features to be released in 2.8:

 https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#

 Please share your feedback.

 Thanks,

 Goktug

>>> --
>>> 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.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/CABb_3%3D62mQ0iqjRBc8E8vbPTWqtE61gUcb-1qbKATt8wtrsUTw%40mail.gmail.com
> 

Re: [gwt-contrib] Re: New JsInterop document

[Manuel Carrasco Moñino]

Another issue in the new implementation is that it's not supported any more
static shared fields in JsType native interfaces, I think if we support
static methods we should support static fields as well, or is there i any
reason to prevent it ?.

On Tue, Nov 10, 2015 at 6:11 PM, Manuel Carrasco Moñino 
wrote:

> var args sounds pretty good, but some kind of overloading based on the
> number of parameters like we had in gwt-exporter should cover many use
> cases, compiler could give an error (like it does now) when it sees two
> methods with the same-number-of-parameters signature.
>
>
>
> On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT
> Contributors  wrote:
>
>> No plan to support through Java implementors, although there are plans to
>> support varargs which would let you accomplish something similar.
>> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino" 
>> wrote:
>>
>>> I see, it works, thanks.
>>>
>>> Any plan to work as well with gwt exported classes ?
>>>
>>> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix <
>>> julien.dram...@gmail.com> wrote:
>>>
 Method overloading works in native JsType JsType(isNative=true)

 On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
 man...@apache.org> wrote:

> Seems that method overloading is not working anymore with JS_RC mode,
> it was working in JS mode though:
>
> Example:
>
>boolean validate()
>boolean validate(String foo)
>
> Is it a feature not implemented yet, or it is not in the specification?
>
> Thanks
> - Manolo
>
>
> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi 
> wrote:
>
>> Thanks Julien!!!
>>
>> This work fine!!
>>
>> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
>> escribió:
>>>
>>> As we are getting close to 2.8 release I wrote a new document that
>>> is concentrating on jsinterop features to be released in 2.8:
>>>
>>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>>
>>> Please share your feedback.
>>>
>>> Thanks,
>>>
>>> Goktug
>>>
>> --
>> 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.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/CABb_3%3D62mQ0iqjRBc8E8vbPTWqtE61gUcb-1qbKATt8wtrsUTw%40mail.gmail.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/CAM28XAtTjvgcdJLojY4C4ouNzDUOBOXTF_TKjxRA8V2Azjoecw%40mail.gmail.com
>>> 

Re: [gwt-contrib] Re: New JsInterop document

[Manuel Carrasco Moñino]

var args sounds pretty good, but some kind of overloading based on the
number of parameters like we had in gwt-exporter should cover many use
cases, compiler could give an error (like it does now) when it sees two
methods with the same-number-of-parameters signature.



On Tue, Nov 10, 2015 at 5:59 PM, 'Roberto Lublinerman' via GWT Contributors
 wrote:

> No plan to support through Java implementors, although there are plans to
> support varargs which would let you accomplish something similar.
> On Nov 10, 2015 08:53, "Manuel Carrasco Moñino"  wrote:
>
>> I see, it works, thanks.
>>
>> Any plan to work as well with gwt exported classes ?
>>
>> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix > > wrote:
>>
>>> Method overloading works in native JsType JsType(isNative=true)
>>>
>>> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>
 Seems that method overloading is not working anymore with JS_RC mode,
 it was working in JS mode though:

 Example:

boolean validate()
boolean validate(String foo)

 Is it a feature not implemented yet, or it is not in the specification?

 Thanks
 - Manolo


 On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi 
 wrote:

> Thanks Julien!!!
>
> This work fine!!
>
> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
> escribió:
>>
>> As we are getting close to 2.8 release I wrote a new document that is
>> concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.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/CABb_3%3D62mQ0iqjRBc8E8vbPTWqtE61gUcb-1qbKATt8wtrsUTw%40mail.gmail.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/CAM28XAtTjvgcdJLojY4C4ouNzDUOBOXTF_TKjxRA8V2Azjoecw%40mail.gmail.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/CAC7T7gk0jt7HDS

Re: [gwt-contrib] Re: New JsInterop document

['Roberto Lublinerman' via GWT Contributors]

No plan to support through Java implementors, although there are plans to
support varargs which would let you accomplish something similar.
On Nov 10, 2015 08:53, "Manuel Carrasco Moñino"  wrote:

> I see, it works, thanks.
>
> Any plan to work as well with gwt exported classes ?
>
> On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix 
> wrote:
>
>> Method overloading works in native JsType JsType(isNative=true)
>>
>> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino 
>> wrote:
>>
>>> Seems that method overloading is not working anymore with JS_RC mode, it
>>> was working in JS mode though:
>>>
>>> Example:
>>>
>>>boolean validate()
>>>boolean validate(String foo)
>>>
>>> Is it a feature not implemented yet, or it is not in the specification?
>>>
>>> Thanks
>>> - Manolo
>>>
>>>
>>> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi 
>>> wrote:
>>>
 Thanks Julien!!!

 This work fine!!

 El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
 escribió:
>
> As we are getting close to 2.8 release I wrote a new document that is
> concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>
 --
 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.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/CABb_3%3D62mQ0iqjRBc8E8vbPTWqtE61gUcb-1qbKATt8wtrsUTw%40mail.gmail.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/CAM28XAtTjvgcdJLojY4C4ouNzDUOBOXTF_TKjxRA8V2Azjoecw%40mail.gmail.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/CAC7T7gk0jt7HDSPDX22f9LX5SLdxK8Hm9D1rzo92ac2qzoMXHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Manuel Carrasco Moñino]

I see, it works, thanks.

Any plan to work as well with gwt exported classes ?

On Tue, Nov 10, 2015 at 5:33 PM, Julien Dramaix 
wrote:

> Method overloading works in native JsType JsType(isNative=true)
>
> On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino 
> wrote:
>
>> Seems that method overloading is not working anymore with JS_RC mode, it
>> was working in JS mode though:
>>
>> Example:
>>
>>boolean validate()
>>boolean validate(String foo)
>>
>> Is it a feature not implemented yet, or it is not in the specification?
>>
>> Thanks
>> - Manolo
>>
>>
>> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi 
>> wrote:
>>
>>> Thanks Julien!!!
>>>
>>> This work fine!!
>>>
>>> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
>>> escribió:

 As we are getting close to 2.8 release I wrote a new document that is
 concentrating on jsinterop features to be released in 2.8:

 https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#

 Please share your feedback.

 Thanks,

 Goktug

>>> --
>>> 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.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/CABb_3%3D62mQ0iqjRBc8E8vbPTWqtE61gUcb-1qbKATt8wtrsUTw%40mail.gmail.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/CAM28XAtTjvgcdJLojY4C4ouNzDUOBOXTF_TKjxRA8V2Azjoecw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Julien Dramaix]

Method overloading works in native JsType JsType(isNative=true)

On Tue, Nov 10, 2015 at 5:15 PM Manuel Carrasco Moñino 
wrote:

> Seems that method overloading is not working anymore with JS_RC mode, it
> was working in JS mode though:
>
> Example:
>
>boolean validate()
>boolean validate(String foo)
>
> Is it a feature not implemented yet, or it is not in the specification?
>
> Thanks
> - Manolo
>
>
> On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi 
> wrote:
>
>> Thanks Julien!!!
>>
>> This work fine!!
>>
>> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
>> escribió:
>>>
>>> As we are getting close to 2.8 release I wrote a new document that is
>>> concentrating on jsinterop features to be released in 2.8:
>>>
>>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>>
>>> Please share your feedback.
>>>
>>> Thanks,
>>>
>>> Goktug
>>>
>> --
>> 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.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/CABb_3%3D62mQ0iqjRBc8E8vbPTWqtE61gUcb-1qbKATt8wtrsUTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Manuel Carrasco Moñino]

Seems that method overloading is not working anymore with JS_RC mode, it
was working in JS mode though:

Example:

   boolean validate()
   boolean validate(String foo)

Is it a feature not implemented yet, or it is not in the specification?

Thanks
- Manolo


On Mon, Nov 9, 2015 at 3:40 PM, Cristian Rinaldi 
wrote:

> Thanks Julien!!!
>
> This work fine!!
>
> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
> escribió:
>>
>> As we are getting close to 2.8 release I wrote a new document that is
>> concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> 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/51f767f9-0afd-48fd-bef8-a9106b0d716a%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/CAM28XAtrYCKBHtp6ccqnxTq%3Dq2EK8jB-A57qqFX05U2sw6-12w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: New JsInterop document

[Cristian Rinaldi]

Thanks Julien!!!

This work fine!!

El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan 
escribió:
>
> As we are getting close to 2.8 release I wrote a new document that is 
> concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>

-- 
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/51f767f9-0afd-48fd-bef8-a9106b0d716a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

[Julien Dramaix]

Create a native JsType (isNative=true)  named Promise with namespace set to
GLOBAL and define both constructors. It should work.

@JsType(isNative = true, namespace = JsPackage.GLOBAL)
public class Promise {
public Promise(PromiseFn fn){};
}


On Mon, Nov 9, 2015 at 2:57 PM Cristian Rinaldi  wrote:

> Goktug:
>Nice Work!!
>
>How can we handle constructors of native types that receive parameters?
>By Example Promise in JS:
>
>
> new Promise(*executor*);
> new Promise(function(resolve, reject) { ... });
>
>
> I resolve with a static method and JSNI:
>
> public final static native Promise createPromise(PromiseFn fn) /*-{
> return new $wnd.Promise(fn);
>  }-*/;
>
> @FunctionalInterface
> @JsFunction
> public interface PromiseFn {
> void call(ResolveFn resolve, RejectedFn rejected);
> }
>
> @FunctionalInterface
> @JsFunction
> public interface RejectedFn {
> void rejected(Object objs);
> }
>
>
> @FunctionalInterface
> @JsFunction
> public interface ResolveFn {
> void resolve(Object objs);
> }
>
> There is a more correct way to do this?
>
>
> El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan
> escribió:
>>
>> As we are getting close to 2.8 release I wrote a new document that is
>> concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> 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/bd13754e-f451-4de9-a763-50b571762909%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/CABb_3%3D5ORSsuxYPMi8ZXOwSafFb8BRVXaTbUtkt00tySnY5XUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: New JsInterop document

[Cristian Rinaldi]

Goktug:
   Nice Work!!

   How can we handle constructors of native types that receive parameters?
   By Example Promise in JS:
   

new Promise(*executor*);
new Promise(function(resolve, reject) { ... });

   
I resolve with a static method and JSNI:

public final static native Promise createPromise(PromiseFn fn) /*-{
return new $wnd.Promise(fn);
 }-*/;

@FunctionalInterface
@JsFunction
public interface PromiseFn {
void call(ResolveFn resolve, RejectedFn rejected);
}

@FunctionalInterface
@JsFunction
public interface RejectedFn {
void rejected(Object objs);
}


@FunctionalInterface
@JsFunction
public interface ResolveFn {
void resolve(Object objs);
}

There is a more correct way to do this?

El viernes, 23 de octubre de 2015, 4:13:55 (UTC-3), Goktug Gokdogan 
escribió:
>
> As we are getting close to 2.8 release I wrote a new document that is 
> concentrating on jsinterop features to be released in 2.8:
>
> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>
> Please share your feedback.
>
> Thanks,
>
> Goktug
>

-- 
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/bd13754e-f451-4de9-a763-50b571762909%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: New JsInterop document

['Goktug Gokdogan' via GWT Contributors]

Yes, no overloads in Java side as we don't automatically generate dispatch.
Either you need to rename or you can create a send(Object) and dispatch
manually to other methods.

On Fri, Oct 23, 2015 at 1:57 AM, Jens  wrote:

> What about method overloading on Java side? Doesn't seem to be mentioned
> in the doc so I guess its not supported and we would need to rename methods
> on Java side? E.g.
>
> class Foo {
>   @JsMethod(name = "send")
>   public native void sendString(String s)
>
>   @JsMethod(name = "send")
>   public native void sendBlob(Blob b)
> }
>
>
> -- 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/90a200f5-07b3-4beb-934f-d90dc1d7f33c%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%3DyUA22_1qDx3w-%2BYMN2a2v5MufuNcHA4%3DL6%3DW-Avx5LQyJ8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: New JsInterop document

[Jens]

What about method overloading on Java side? Doesn't seem to be mentioned in 
the doc so I guess its not supported and we would need to rename methods on 
Java side? E.g.

class Foo {
  @JsMethod(name = "send")
  public native void sendString(String s)

  @JsMethod(name = "send")
  public native void sendBlob(Blob b)
}


-- 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/90a200f5-07b3-4beb-934f-d90dc1d7f33c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.