OO approach to decision sequence?

[Paul McGuire]

Ok, I'm glad you guys liked that design pattern.  Here are a few
additional footnotes:

1. As George mentions, the order of the converters is *very* important,
especially in this particular case.  One might question whether '1+0j'
would convert to a complex or an int - my first thought was to make it
an int, but that made the example more complicated, and I didn't really
need to be fussy to make the example.

2. If this were a design for a deserializer, it would be a bit poor, if
only because of this order-sensitivity.  Also, there is no way to
reconstruct a string containing a value that maps to one of the other
types, such as 'True' or '1'.  A better deserialize/serialize design
would support quoted strings so that a string of '"1"' would not be
misinterpreted as an int.  But again, I didn't want to take on
deconstructing quoted strings, escaped characters, etc.  But in
general, when designing a deserializer/serializer, it's better to make
the output more unambiguous.

3. I once had an O-O expert tell me that this was not really a
Chain-of-Responsibility pattern.  His take was that, in COR, each link
succeeds, or calls the next link in the chain.  In my design, each link
is just one of a collection, and succeeds or raises an exception; the
iteration is done from the calling routine.  I really haven't found a
name for this pattern, so I just call it "modified COR".

-- Paul