[ruby-talk:17850] Re: Specialised data structures - good or bad?

On Sun, 15 Jul 2001, Shan-leung Maverick WOO wrote:

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

I considered the possibility of inheriting from Array to create Set, which
would re-use the API as you've suggested.

However, this still creates another class with the problem of "-" meaning
one thing for Array and another for Set. It's different and it's still
something I have to remember.

The method calls have to be identical on all objects if I'm only to have
a few simple things to remember. This is the approach Ruby took...

  The String is a supertype for an ASCII character, a multibyte character,
  a group of characters, a block of data, an array of bytes, and so on.

  The Array is a supertype for lists, queues, circular buffers, blocks of
  data, collections, ordered lists, binary trees, and so on.

  The Hash is a supertype for namespaces and random access to data. I'm
  faltering a bit on this point since Array and Hash have always seemed
  a bit too similar in concept to warrant separate concepts. [*]

Something has to give - either the code has to more precisely mean what
the programmer wanted (customised Lego), or the code can be re-expressed
in a, perhaps more inefficient, form to use what's already there (Lego
that can be shared).

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

This is a good point, but I believe it is a separate concept. Before
writing new versions of "chomp", "replace", "slice" for your NewString
class, you need the standard String semantics to copy.

The fact there is only String, Hash or Array gives you some very solid
semantics to copy. If there were many classes in the standard library,
there would be more standards, and the more standards there are, the
less actually happens! :)

If there were Set, Bag, OrderedHash, BinaryTree, RedBlackTree classes
as well, which semantics are you going to copy in the object you're
passing to my code? Even worse - what semantics am I going to expect
to be implemented in the objects you pass to my code?

> Your concern seems to me that the other programmers will just use them
> because these newer containers are fancier.

My concern is that programmers use what they know. Collectively, a
group of programmers know more than a single programmer. Therefore,
when reading collective code, I have to know ALL the APIs that the
collective knows.

As a single programmer, I'm being forced to perform at the level of
the collective just to be able to read other people's code.

Ruby cuts the collective knowledge back to a manageable level.

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

Even better, from my code reader's perspective, would be code not using
red-black trees at all. More understandable code for more inefficient
implementation. After all, you're using a scripting language so you can't
be all that concerned about optimum efficiency.

My eyes have rights too. :)



[*]: If Array could take non-integer indexes, then Hash wouldn't be
     needed anymore... even if it's implemented as a Hash internally
     and self-converts like Integer/Bignum.

-- 
  [e-mail]