> > 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 [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. For more options, visit https://groups.google.com/d/optout.
