[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2011-09-15 Thread codesite-noreply
Comment by pclog...@gmail.com: The best poker blog http://poker-blogs-see.blogspot.com Best PokerStars blog http://pokerstars-blogs.blogspot.com Sexy, hot girls imagehttp://china-sexy-girl-images.blogspot.com/ For more information:

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2011-05-27 Thread codesite-noreply
Comment by spoon.re...@gmail.com: The containsKey(), get(), and remove() methods for Map and MutableMap should take type Object and not K (same as the Java Map interface). The reason is that it is possible for objects of different classes to be .equals() (e.g. all implementations of

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2011-01-27 Thread codesite-noreply
Comment by javierfe...@gmail.com: Any update on this? Thanks For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-08-10 Thread codesite-noreply
Comment by natewingone: @br...@google.com: It's not just mobile apps that want every byte to count. If you use GWT to enhance a largely static website, and the website must be fast to load for new users, you have to make sure javascript is as small as possible. For comparison the current

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-06-30 Thread codesite-noreply
Comment by br...@google.com: @mmoossen: As the name hints, there are significantly different design goals for these collections than for the Guava collections. These collections are meant to be the guilt-free primitives: the lightest conceivable way to implement basic collections on top of

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-04-01 Thread codesite-noreply
Comment by mmoossen: would not it be better to enhance Google Collections (http://code.google.com/p/google-collections/) instead of re-inventing the wheel once again? i mean, i follow the contrib group, and i have seen many discussions about implementation problems (or decisions) that

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-07 Thread codesite-noreply
Comment by rj...@google.com: Given the goal of Collections must be able to be eval()-ed into existence from JSON, I hope their JRE counterparts will be able to serialize to JSON. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections --

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-05 Thread codesite-noreply
Comment by rj...@google.com: I'm very uncomfortable with the Keep implementations locked down assertion. So long as its very clear which implementations have been vetted by the GWT team, why should we prevent clients from providing their own when they judge it to be worth the performance

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-05 Thread codesite-noreply
Comment by rj...@google.com: Has any thought been given to bridging from the JRE collection world to the GWT collection world, and back again? Server side this will be crucial, and if we don't address all of our users will be forced to. Perhaps we would only provide JRE implementations of

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-05 Thread codesite-noreply
Comment by rj...@google.com: I'm with John T about the freeze() method: encouraging people to retroactively lock down an existing array instance seems like a bad idea. Like he says, the smart ones will make defensive copies anyway, so why don't we simply do the same and make the mistakes

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-05 Thread codesite-noreply
Comment by tsta...@google.com: What about bounds checking? I know that GWT goes to great lengths to emulate array bounds checking with java arrays. I assume that this would go away with these collections. For more information:

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-03 Thread codesite-noreply
Comment by andre.ruediger: vararg convenience factory methods would be handy. --- MutableArrayString ma = makeSnackArray(); --- ImmutableArrayString ia = ma.freeze(); +++ ImmutableArrayString ia = createImmutableArray(apple, banana, coconut, donut); For more information:

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-03 Thread codesite-noreply
Comment by andre.ruediger: vararg convenience factory methods would be handy. so {{{MutableArray?String ma = makeSnackArray(); ImmutableArray?String ia = ma.freeze();}}} could become {{{ImmutableArray?String ia = createImmutableArray(apple, banana, coconut, donut);}}} For more

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-03 Thread codesite-noreply
Comment by andre.ruediger: vararg convenience factory methods would be handy. so {{{MutableArrayString ma = makeSnackArray(); ImmutableArrayString ia = ma.freeze();}}} could become {{{ImmutableArrayString ia = createImmutableArray(apple, banana, coconut, donut);}}} For more

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-03-03 Thread codesite-noreply
Comment by andre.ruediger: vararg convenience factory methods would be handy. so {{{ MutableArrayString ma = makeSnackArray(); ImmutableArrayString ia = ma.freeze(); }}} could become {{{ ImmutableArrayString ia = createImmutableArray(apple, banana, coconut, donut); }}} For more

[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit

2010-02-03 Thread codesite-noreply
Comment by spoon.reloaded: The declaration for printEach() should be simplified to: `public void printEach(Array? arrToPrint) {` For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors