From: Ryan Leavengood Date: 2006-05-26T00:59:06+09:00 Subject: Re: Equivalent of collections in Java On 5/25/06, Robert Klemme wrote: > > The static typing of Java is *not* responsible for the comparatively > large number of collection classes. All Java collections are based on > Object as element type which is as generic as it can get without > generics. Let me clarify: I think the design of Java, including the static typing, results in a large number of highly specified and frequently not interchangeable Collection classes. I feel this is a negative. > Java collections indeed offer more *functionality*: these are the > collection types which do not have an equivalent in Ruby's std lib: > TreeSet, TreeMap, LinkedList, IdentityHashMap, Stack and the > synchronized Collections Vector and Hashtable. I think having to guess which one of these you want to use based on perceived need is a form of premature optimization, and this overly complicates the development process. How many Ruby programs have truly needed classes like the above? Also Ruby's Array can act much like Java's Stack. > That's not against OO at all. All classes have certain > characteristics - algorithmic complexity being one of them. It's > perfectly valid to have several implementations of the same concept > (aka interface) from which a developer can pick the most appropriate > for the solution he wants to build. In fact, OO usually makes > exchanging one implementation for another much easier through > inheritance (duck typing in Ruby). Java does not have duck typing and in fact most of the Collection classes are not at all interchangeable, unless you stick to the interfaces of their common abstract parent classes (which removes much of the benefit of their specialization.) I think in Ruby there are only a few specialized cases that would require changing the algorithm behind a data structure, and if speed is that important profiling will find the true culprits slowing things down, which frequently will not be the data structures. Ryan