On Wed, Feb 15, 2017 at 3:33 PM, Ming-Yee Iu <[email protected]> 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 [email protected]. > 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 > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/827ac42b-638f-49f4-b67b-0f3675808879%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. 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.
