From: Robert Klemme <shortcutter@...>
Date: 2007-01-24T19:50:05+09:00
Subject: Re: a Hash and a Set (sitting in a tree)

On 24.01.2007 10:43, Shot (Piotr Szotkowski) wrote:
> (For those keeping track at home of my Ruby vs. Ruby/C vs. C++
> adventures, I decided to go with pure Ruby and optimise afterwards
> if/where needed and my supervisor agreed. I also started coding
> yesterday, and would like to state that (a) Ruby test-driven development
> is even more sexy than advertised and (b) humblelittlerubybook.com is
> a really great book.)
> 
> On to my problem, then. :) First, the terminology: a block is a set of
> vectors (say, integers), a blanket is a set of blocks, and a blanket
> might be, but in most cases isn�t, encoded � i.e., might have its blocks
> named. Thus an example, unencoded two-block blanket might look like
> this: {{1, 9, 4, 7}, {1, 9, 3, 7}}
> 
> My obvious first approach was to create a Block class with two
> properties, a @vectors Set and an @encoding Symbol, and a Blanket
> class with a @blocks Set.
> 
> Now that I think about it, though, most of the computing will happen
> with unencoded blankets, and in this case there�s no need for a Block
> class at all; just a Blanket with a Set of Sets. First, this (I presume)
> would make things a bit faster and less memory hungry; second, the
> encoding makes sense only at the Blanket level, really.
> 
> Ufortunately, an encoded blanket screams to be represented as a Hash of
> Sets (keyed with the encoding Symbols), while an unencoded blanket is
> best represented as a Set of Sets, and can�t be a Hash. 
> 
> What would be the best approach to this situation? An EncodedBlanket
> subclass of Blanket? A Blanket class that is a Hash of Symbols keyed
> with Sets (i.e., the other way around, with nil hash values for
> unencoded blankets)? Something else? Basically, what I need is
> a hash that doesn�t have to have keys�

Initially I would defer considerations of performance.  I'd start with 
the cleanest design.  At the moment I don't have any clue as to what 
processing you are doing so that would probably determine how I would 
set up classes.  The most straightforward way would probably be to have 
a BaseBlanket, an EncodedBlanket, a PlainBlanket (unencoded) and a Block.

Whether the BaseBlanket makes sense is probably determined by how much 
an EncodedBlanket and a PlainBlanket have in common, i.e. how much 
functionality they share.  That then would go into the BaseBlanket.

Kind regards

	robert