> - only doubles while int would make sense here and there we are aware of that. That should be solved before the first release
> - no use of generics and enums generics are used (look at NativeArray ot HtmlCollection). Enums not yet > - no packages. Would be nice to have things like dom, crypto, promise, audio, webgl, etc. it's planned > - often method signature defines Object as return type while I am pretty sure something more concrete would be more appropriate. if a method "getFoo" can return different types "string or Foo", we create different methods : public Object getFoo(); public String getFooAsString(); public Foo getFooAsFoo(); In the future there will be javadoc above the methods mentioning these links between a set of methods. > - obviously no JavaDoc, but it would be nice to have. Especially for people working in a no-internet environment. As mentioned above, it's planned > - edge cases like EventTarget.addEventListener(EventListener) and EventTarget.addEventListener(AddEventListenerListenerCallback) that should be cleaned up I don't think we will clean that up. At least it's not planned. On Mon, Jul 4, 2016 at 6:32 PM Jens <jens.nehlme...@gmail.com> wrote: > > I do think we should have another library that builds on Elemental2. While >> browser compatibility is a lot better, it still isn't perfect and we need >> somewhere to collect workarounds for specific issues and add helper >> functions to make working with the library easier. >> > > But then you have the GWT overhead on top of it again. But I tend to agree > that a purely generated API can never be that nice to use as a hand crafted > one. I have only taken a very brief look at the generated code of the > elemental2 snapshot build but I think my major points are: > > - vendor prefixes. Sticking to standard API and asking devs to polyfill > them if needed sounds better to me. Avoids potential API duplication. > - only doubles while int would make sense here and there > - no use of generics and enums > - no packages. Would be nice to have things like dom, crypto, promise, > audio, webgl, etc. > - often method signature defines Object as return type while I am pretty > sure something more concrete would be more appropriate. > - obviously no JavaDoc, but it would be nice to have. Especially for > people working in a no-internet environment. > - edge cases like EventTarget.addEventListener(EventListener) and > EventTarget.addEventListener(AddEventListenerListenerCallback) that should > be cleaned up > > Maybe it is worth thinking about providing some patch files in addition to > the generator to fix some stuff that are hard to fix inside the elemental2 > generator. Given that existing non-prefixed API does not change these patch > files should be pretty stable and always applicable. > > -- 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/71f5352a-41dc-4f91-a22b-9a9bb21b8bbb%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/71f5352a-41dc-4f91-a22b-9a9bb21b8bbb%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 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%3D47SY%2BY%3DOV05bCFj41PecQXTEbx-Wgqazh0KJznt8g-Kw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
