On Wed, Jun 17, 2009 at 7:33 PM, Stefan Haustein <[email protected]>wrote:
> Our main problem is code size, so "ambitious" scares me :) > I'm glad to hear it -- your paranoia stems from dedication to a creating great user experience. That's an A+ reaction in my book :-) The bottom describes why it's "ambitious" in a bit more detail. The actual problem at hand is that GWT runasync stuff drags in LinkedList > which is used nowhere else, so having our own copy of JsArray in our project > won't really help (And my CL for replacing Hashtable with our own > JsStringMap slowly deteriorates because I realized that Hashtable is used in > GWT internally in libraries we cannot replace easily). > Yes, we need to replace those uses as soon as we can. I really hope the new collections can be ready really soon, but even if not, we can do temporary lighter-weight collections so that you can escape JRE collections. > Why not release early and start with a basic copy of JsArray and then add > more functionality (e.g. iterable) later? > Collections are very, very amenable to bikeshedding, so I want to have a pretty well thought-out plan so as to avoid endless "what if" threads, if at all possible. Of course, if the design is bad, people will hopefully say so and we'll do something different. But I just don't want to start with so little that it doesn't have enough intertia to achieve escape velocity. When I say "ambitious" I mean that it's ambitious in its design goals, not in its implementation. The key thing we need to do is make the collection attractive enough that people will feel comfortable using them on the server side, too. This is important because otherwise, they'll use JRE collections in RPC, which will mean the client-side code will be *worse*, because it will probably have both sets of collections and still more code to convert from JRE collections to GWT collections, and so on. A related set of design goals is to have rich enough type hierarchy that people can feel very confident avoiding defensive code. Patterns like "clone collections if you're not sure they're not aliased by someone else" are death in JS, as I'm sure you know well. We need collections that can express concepts like immutability statically, so that developers will simply know that there's no need to defensively clone them. Stuff like that: smarter choice of types so as to require *less* code in the client, and make 'em more optimizable, too. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
