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

On 24.01.2007 12:41, Shot (Piotr Szotkowski) wrote:
> Thanks a lot for your reply, Robert!
> 
> Robert Klemme:
> 
>> 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.
> 
> Mostly basic set operations on the blocks; Set#&, Set#|,
> Set#- and Set#^ seem to cover quite a lot of the base.

And how do you access or find blocks (and blankets)?

>> The most straightforward way would probably be to have a BaseBlanket,
>> an EncodedBlanket, a PlainBlanket (unencoded) and a Block.
> 
> With this approach (i.e., moving the encoding information to the blanket
> level, which actually makes sense) Block would be just a Set, nothing
> more.

Well, but with a block you get clear semantics at the price of a low 
overhead.  The way you speak of blocks seems to indicate to me that 
there is more to them which then would make them a good thing to have. 
At least it's much easier to later add methods to Block than changing 
the whole code from Set to Blanket if at some point in time you discover 
that you need additional methods.

>> 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.
> 
> In theory, EncodedBlanket is just a Blanket with its blocks named,
> so a Blanket class with an EncodedBlanket subclass should cover it.

Maybe.

> The catch is, an unencoded blanket can be represented as a Set of
> blocks, while and encoded blanket can�t; conversely, an encoded blanket
> can be represented as a Hash of (encoding => block) pairs, while an
> unencoded blanket can�t.

You should probably try to look at it more from the interface 
perspective: you talk a lot about internal representation while I think 
it's more important to get the interface straight.  Questions I would as 
are: what entities are there?  How are they connected?  How are they 
used? etc.  (You could do this on a whiteboard or with CRC cards as well.)

> Maybe I should go with a single Blanket class with an Array of blocks
> and a �synchronised� Array of encodings that would simply be nil for
> unencoded blankets? I don�t need the ordering Array would bring in,
> but a common class for un- and encoded blankets would simplify things
> greatly.

In that case it's you could also have a single Array containing two 
element Arrays (Blanket, Encoding).  Whether to use that, your version 
or a Hash is mostly determined by how you access (i.e. do you need the 
encoding as a key?).

Kind regards

	robert