From: Robert Klemme <shortcutter@...>
Date: 2006-05-26T15:41:00+09:00
Subject: Re: Equivalent of collections in Java

2006/5/25, Ryan Leavengood <leavengood@gmail.com>:
> On 5/25/06, Robert Klemme <shortcutter@googlemail.com> 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.

Again, static typing is not responsible for the number of collection
classes because variation is on functionality, invariants, algorithmic
complexity - and not on type.

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

Yes, and so can Java's LinkedList.  This doesn't make a Stack class superfluous.

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

With all due respect, what you wrote shows that you lack some basic
understanding of software engineering. Choosing between a Set and a
List is by far not a premature optimization but a deliberate design
decision.  Knowing algorithmic properties of these basic abstract data
types is one of the required skills of someone engaged in software
engineering - even if Ruby has only so few of them, and probably needs
less of them because of its design.  I suggest you get yourself a book
on Data Structures and Algorithms (for example the excellent books of
Robert Sedgewick) and digest it.

Kind regards

robert

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/