Stephen White wrote:

> It seems to me that much of the power of Ruby comes from the ability of
> code to communicate with each other. This stems from the re-use of common
> constructs - strings, arrays and hashs - for everything.

I don't know if this is the correct reasoning or not. To me, it seems it is
the re-use of common _abstractions_ (API, if you will), not the actual
_constructs_. 

For example, when I am enumerating a container, most of the time I don't
really don't care if it is a Hash, an Array, or a (future) Dictionary (if it
exists). All I care should be the fact that they have "each" implemented
correctly. If I go beyond that part and use, say, "flatten", then I restrict
my code to Array only (or anything else that supports flatten). Also think
about the Enumerable mixin.

The fact that Ruby is untyped means that if someone pass you a Dictionary
instead of the old-good-friendly Hash should not break your code, if you
code does not assume it is a Hash in the beginning. And if you assume it is
a Hash because of, say, performance reasons, then you should document it and
make sure your user will not pass you anything other than a Hash or
something inherits from it. This will exclude the old-good-friendly Array
and having common constructs will not buy you anything if your code is so
much coupled with the actual implementation (sometimes it's necessary).

> operations, including the ones in my head, will work. I don't have to
> race off to learn yet another API for yet another class.

This assumes that the other programmers will use those newer containers. And
assuming they do that with a good reason, then I don't feel the need to
restrict them from doing what they think is appropriate just because I don't
like to learn the new API before I can read their code. Your concern seems
to me that the other programmers will just use them because these newer
containers are fancier. If that is really your concern, then I am
speechless.

Also, this point is also related to what abstraction the container author
builds around it. If you assume it's going to be a lame abstraction (say one
that doesn't support each), then I agree that your mind should not be
polluted with such. 

Maybe I am naive, but I really don't see much harm to have more fancy
container classes with nice abstraction and let people use them if they mean
to. To me, having a standardized dictionary in C++ STL is much better than
seeing ten-thousand different red-black tree implementations all without a
common interface. But YMMV, especially when the language under concern is
Ruby.

Again, just my 2 cents.

-- 
All the best,
Maverick Woo