[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:
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

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 java.util.List are equal if their  
contents are equal, regardless of class), so the object that one passes to  
containsKey(), get(), or remove(), need not be the same type as the type of  
the keys inside the map.


I see that you have already adopted Object for your Set's contains()  
method. So it would make sense to do it for Maps too.


For the same reason, the argument to Set and MutableSet's containsAll(),  
containsSome(), isEqual(), keepAll(), and removeAll() should be changed  
from `SetE` to `Set?`, because they only check elements for equality,  
and for that it doesn't matter the class.


For more information:
https://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

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 collections are used all  
over the place in the widget/event libraries, and ArrayList alone uses  
around 8k.



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-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 JS that are so  
small/fast that they remove all temptation to do it by hand in JS  
instead. Something like a GWT port of Guava Collections would likely be  
built on top of these (rather than using hand-coded JSNI). Especially when  
you consider mobile web apps, every byte counts, and you really have to  
design low-level libraries like this to the target platform.



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-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 are already solved in Google  
Collections... so i have the feeling some very good developers are just  
wasting their time here...




For more information:
http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe, reply using remove me as the subject.


[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

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


[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 risk?



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-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 such code to discourage such mistakes  
client side.



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-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 impossible?


The current change it at runtime and take your chances proposal seems  
very un-GWTlike.



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-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:
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-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:
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-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 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-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 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-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 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-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