Re: [gwt-contrib] Re: Experimental release of Elemental2

['Goktug Gokdogan' via GWT Contributors]

On Wed, Feb 15, 2017 at 3:33 PM, Ming-Yee Iu  wrote:

> a) it's inconsistent with Java semantics,
>>>
>>
>> This could be a stylistic inconsistency not a semantic one. All arguments
>> that I have seen in favor for having accessors instead of fields are
>> inapplicable to Elemental fields since they all assume changes in the
>> implementation of accessors which in our case always a pass through.
>>
>> However I am aware of the stylistic expectation from some java devs and
>> we might end up providing setter/getter as overlays for people who would
>> like to stick conventional style.
>>
>
> I guess I'm referring to how field access in Java are simply variable
> modifications whereas property accesses in JavaScript can trigger
> additional behaviors. In normal Java code, something like
>
>canvas.width = 50
>
> is pretty inert. But in Elemental, that code automatically triggers a
> resizing and relayout of the element. Or perhaps a better example is
> innerHTML. Or even something like
>
>el.scrollTop = -5;
>System.out.println(el.scrollTop);   // prints out 0, which this is
> impossible in real Java
>
> I'm not sure whether these would be described as semantic or stylistic
> differences. But they're unexpected.
>

I don't consider this strictly related accessor vs. field. Javascript
interoperation in general could have such unexpected behavior and it is
surprising in both scenarios. A developer should always be aware Elemental
is actually calling into browser.


>
>
>>>  c) it's harder to mock the behavior of the classes for unit tests
>>>
>>
>> Actually a field doesn't require mocking; but native accessor as you are
>> proposing does require mocking.
>>
>
> Well, it sort of depends. Since JavaScript properties actually trigger
> additional behaviors, I might want to mock the properties to ensure these
> behaviors are being triggered correctly. I might want to mock innerHTML to
> ensure that the correct UI is being set-up and then use that trigger some
> additional mocking. (Or is this not mocking? I'm unclear on the correct
> test terminology for that.) I suppose that things can be worked around by
> just testing field values. And I'm not sure if people actually unit test
> user interfaces like that. It's just a trade-off, I suppose.
>

If your test depends on additional behavior that would be normally
triggered by setting innerHtml, I think at that point you should not test
that code by mocking elemental. (Actually in general most code that relies
on elemental better be tested without mocking - it is much better to test
with actual browser behavior.)


>
>
>>
>>
>>> 4. Also, is it possible to supplement the typing information for some of
>>> those callbacks from Typescript? Everyone knows that "onclick" handlers
>>> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or
>>> is sufficiently well-developed to generate the best API there.
>>>
>>
>> The language gap between TypeScript and Java is actually higher than
>> Closure and Java. That makes it harder to precisely mimic type info that
>> exists in d.ts via Java abstractions.
>>
>> Hopefully we could make this work better over time.
>>
>>
>
> Sure. I was just thinking that it would be nice if the code generator
> could suck in additional data from other sources to supplement the info it
> can use to generate interfaces. The hand-built types in TypeScript is a
> good information source for event handlers. And Web IDL has good
> information on whether numbers are integers or floats. I'm just throwing it
> out there as possible future improvements.
>
> --
> 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/827ac42b-638f-
> 49f4-b67b-0f3675808879%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%3DyUA0zXtmZXxQz3L5FFDwqYgtAC3%3DubDqUTt12tiyZ%3DEDVWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

['Julien Dramaix' via GWT Contributors]

The problem with generating getters and setters is that you can potentially
conflict with an existing method. I had this problem when I've generated
the java classes to interacting with the typescript compiler. Some classes
had a field named foo and a method named getFoo() and that's not
necessarily a simple getter.

On Wed, Feb 15, 2017 at 3:34 PM Colin Alworth  wrote:

>
>
> On Wednesday, February 15, 2017 at 4:01:01 PM UTC-6, Goktug Gokdogan wrote:
>
> Thanks for the feedback.
>
>
>
> On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu  wrote:
>
> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java
> fields is the best choice. Sure, it "feels" more like the original
> JavaScript, but
>
>
>
> a) it's inconsistent with Java semantics,
>
>
> This could be a stylistic inconsistency not a semantic one. All arguments
> that I have seen in favor for having accessors instead of fields are
> inapplicable to Elemental fields since they all assume changes in the
> implementation of accessors which in our case always a pass through.
>
> However I am aware of the stylistic expectation from some java devs and we
> might end up providing setter/getter as overlays for people who would like
> to stick conventional style.
>
>
> There are also a variety of tools that assume methods rather than fields -
> uibinder, cssresource, editors all made assumptions about turning dot
> notation into getters (and in the case of editors, setters), and did not
> support fields at all as far as I'm aware. This is true of most (though not
> all) codegen tools I've worked with since as well.
>
> Another advantage: You can't turn a field into a method-reference.
>
>
-- 

Julien Dramaix |  Software Engineer |  dram...@google.com |  650-750-6053

-- 
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/CABXeq2SeEiWTyCJDdUNbeH8mdfTtDOc7SpqcYTPC9eGqH71DpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Colin Alworth]

On Wednesday, February 15, 2017 at 4:01:01 PM UTC-6, Goktug Gokdogan wrote:
>
> Thanks for the feedback.
>
> On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu 
> > wrote:
>
>> Well, ok. Thanks.
>>
>> Just in terms of general feedback on Elemental2:
>>
>> 1. I'm not sure whether the conversion of JavaScript properties to Java 
>> fields is the best choice. Sure, it "feels" more like the original 
>> JavaScript, but
>>
>  
>
>> a) it's inconsistent with Java semantics,
>>
>
> This could be a stylistic inconsistency not a semantic one. All arguments 
> that I have seen in favor for having accessors instead of fields are 
> inapplicable to Elemental fields since they all assume changes in the 
> implementation of accessors which in our case always a pass through.
>
> However I am aware of the stylistic expectation from some java devs and we 
> might end up providing setter/getter as overlays for people who would like 
> to stick conventional style.
>  
>
There are also a variety of tools that assume methods rather than fields - 
uibinder, cssresource, editors all made assumptions about turning dot 
notation into getters (and in the case of editors, setters), and did not 
support fields at all as far as I'm aware. This is true of most (though not 
all) codegen tools I've worked with since as well.

Another advantage: You can't turn a field into a method-reference. 
 

-- 
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/fc44ca94-13d0-4dcd-b3a3-a4098f09a973%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Ming-Yee Iu]

>
> a) it's inconsistent with Java semantics,
>>
>
> This could be a stylistic inconsistency not a semantic one. All arguments 
> that I have seen in favor for having accessors instead of fields are 
> inapplicable to Elemental fields since they all assume changes in the 
> implementation of accessors which in our case always a pass through.
>
> However I am aware of the stylistic expectation from some java devs and we 
> might end up providing setter/getter as overlays for people who would like 
> to stick conventional style. 
>

I guess I'm referring to how field access in Java are simply variable 
modifications whereas property accesses in JavaScript can trigger 
additional behaviors. In normal Java code, something like 

   canvas.width = 50

is pretty inert. But in Elemental, that code automatically triggers a 
resizing and relayout of the element. Or perhaps a better example is 
innerHTML. Or even something like

   el.scrollTop = -5;
   System.out.println(el.scrollTop);   // prints out 0, which this is 
impossible in real Java

I'm not sure whether these would be described as semantic or stylistic 
differences. But they're unexpected.


>>  c) it's harder to mock the behavior of the classes for unit tests
>>
>
> Actually a field doesn't require mocking; but native accessor as you are 
> proposing does require mocking.
>

Well, it sort of depends. Since JavaScript properties actually trigger 
additional behaviors, I might want to mock the properties to ensure these 
behaviors are being triggered correctly. I might want to mock innerHTML to 
ensure that the correct UI is being set-up and then use that trigger some 
additional mocking. (Or is this not mocking? I'm unclear on the correct 
test terminology for that.) I suppose that things can be worked around by 
just testing field values. And I'm not sure if people actually unit test 
user interfaces like that. It's just a trade-off, I suppose.
 

>  
>
>> 4. Also, is it possible to supplement the typing information for some of 
>> those callbacks from Typescript? Everyone knows that "onclick" handlers 
>> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or 
>> is sufficiently well-developed to generate the best API there.
>>
>
> The language gap between TypeScript and Java is actually higher than 
> Closure and Java. That makes it harder to precisely mimic type info that 
> exists in d.ts via Java abstractions.
>
> Hopefully we could make this work better over time.
>  
>

Sure. I was just thinking that it would be nice if the code generator could 
suck in additional data from other sources to supplement the info it can 
use to generate interfaces. The hand-built types in TypeScript is a good 
information source for event handlers. And Web IDL has good information on 
whether numbers are integers or floats. I'm just throwing it out there as 
possible future improvements.

-- 
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/827ac42b-638f-49f4-b67b-0f3675808879%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

['Goktug Gokdogan' via GWT Contributors]

Thanks for the feedback.

On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu  wrote:

> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java
> fields is the best choice. Sure, it "feels" more like the original
> JavaScript, but
>


> a) it's inconsistent with Java semantics,
>

This could be a stylistic inconsistency not a semantic one. All arguments
that I have seen in favor for having accessors instead of fields are
inapplicable to Elemental fields since they all assume changes in the
implementation of accessors which in our case always a pass through.

However I am aware of the stylistic expectation from some java devs and we
might end up providing setter/getter as overlays for people who would like
to stick conventional style.


> b) I'd be afraid that a Java compiler might apply some unexpected
> optimization there as a result,
>

I don't think that's possible.


>  c) it's harder to mock the behavior of the classes for unit tests
>

Actually a field doesn't require mocking; but native accessor as you are
proposing does require mocking.


> and d) alternate implementations of Elemental2 aren't possible (for
> example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I
> did with Elemental 1).
>

I can see how accessor can help with this as it gives you more flexibility
on your  re-implementation of the API.


>
> 2. Personally, I would prefer if Elemental 2 used interfaces over classes
> (for similar reason as above), though I understand that being able to use
> "new ...()" syntax on things is nice too.
>

That is more than that:  https://groups.google.com/d/
topic/google-web-toolkit-contributors/L6uh96NcZtE/discussion


>
> 3. The number of callback classes is out-of-control. Can they be
> consolidated somehow?
>
>
Hopefully next release will cleanup plenty of them.


> 4. Also, is it possible to supplement the typing information for some of
> those callbacks from Typescript? Everyone knows that "onclick" handlers
> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or
> is sufficiently well-developed to generate the best API there.
>

The language gap between TypeScript and Java is actually higher than
Closure and Java. That makes it harder to precisely mimic type info that
exists in d.ts via Java abstractions.

Hopefully we could make this work better over time.


>
> 5. Can there be some magic that makes elemental2.Iterable a real Java
> Iterable?
>

We can probably do something here. Will track that issue.


>
> Otherwise, it seems nice. I like that there's a NodeList now!
>
> --
> 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/ms
> gid/google-web-toolkit-contributors/cb2a997b-2d25-43c0-911a-
> ba13a448e14e%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%3DyUA39_gq7ZyFujZsjq_YkOXP_T%3Dd42H64zpUcgm_BZJaLoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[John Huss]

I agree about preferring "bean" style properties.  It's not a clear choice, 
but using bean style properties is more familiar to java programmers and 
makes the library fit in much better with the wider java ecosystem.  Also 
it would make conversions from elemental 1 much easier (though that is 
probably a very small group of users).

On Wednesday, February 15, 2017 at 3:05:01 PM UTC-6, Ming-Yee Iu wrote:
>
> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java 
> fields is the best choice. Sure, it "feels" more like the original 
> JavaScript, but a) it's inconsistent with Java semantics, b) I'd be afraid 
> that a Java compiler might apply some unexpected optimization there as a 
> result, c) it's harder to mock the behavior of the classes for unit tests 
> and d) alternate implementations of Elemental2 aren't possible (for 
> example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I 
> did with Elemental 1).
>
> 2. Personally, I would prefer if Elemental 2 used interfaces over classes 
> (for similar reason as above), though I understand that being able to use 
> "new ...()" syntax on things is nice too.
>
> 3. The number of callback classes is out-of-control. Can they be 
> consolidated somehow? 
>
> 4. Also, is it possible to supplement the typing information for some of 
> those callbacks from Typescript? Everyone knows that "onclick" handlers 
> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or 
> is sufficiently well-developed to generate the best API there.
>
> 5. Can there be some magic that makes elemental2.Iterable a real Java 
> Iterable?
>
> Otherwise, it seems nice. I like that there's a NodeList now!
>

-- 
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/10a89130-7d9a-4f48-8ab8-3387eefcab49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Ming-Yee Iu]

Well, ok. Thanks.

Just in terms of general feedback on Elemental2:

1. I'm not sure whether the conversion of JavaScript properties to Java 
fields is the best choice. Sure, it "feels" more like the original 
JavaScript, but a) it's inconsistent with Java semantics, b) I'd be afraid 
that a Java compiler might apply some unexpected optimization there as a 
result, c) it's harder to mock the behavior of the classes for unit tests 
and d) alternate implementations of Elemental2 aren't possible (for 
example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I 
did with Elemental 1).

2. Personally, I would prefer if Elemental 2 used interfaces over classes 
(for similar reason as above), though I understand that being able to use 
"new ...()" syntax on things is nice too.

3. The number of callback classes is out-of-control. Can they be 
consolidated somehow? 

4. Also, is it possible to supplement the typing information for some of 
those callbacks from Typescript? Everyone knows that "onclick" handlers 
pass a MouseEvent. I'm not sure if Closure has a rich enough type system or 
is sufficiently well-developed to generate the best API there.

5. Can there be some magic that makes elemental2.Iterable a real Java 
Iterable?

Otherwise, it seems nice. I like that there's a NodeList now!

-- 
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/cb2a997b-2d25-43c0-911a-ba13a448e14e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.