On Sat, 8 Feb 2003 dblack / candle.superlink.net wrote:

> Even if the new class is specialized, substrings of it may not be
> similarly specialized -- in which case, it's misleading to have them
> be instances of the new class.  For example:
>   class Name < String
>     def initial
>       scan(/[A-Z]/)[0]
>     end
>   end
>   n = Name.new("David")
>   i = n.initial          # String in 1.6.8, Name in 1.8.0
> Here, it doesn't seem logical (to me) for an initial to be a Name
> object.  (Yes, I could have done self[0].chr, but I need to illustrate
> this :-)

To me, it doesn't seem logical for the Name class to exist; a Name may be
"a kind of" String, but that doesn't mean it should be a subclass it...
here are a few ideas i've been cooking lately about software modeling (an 
extension of my rants :-} about type checking):

What may appear like a subclass could actually be:

1. a mere "subtype", where "type" here means a set of expectations you
have about an object; for example, you may expect that the object matches
a certain Regexp.

2. a "use", as in, a set of (representational) meanings; at this level of
abstraction you'd distinguish Name from Title from
RGBPictureInTheShapeOfAString.

3. a "role", as in, a place in a relationship, a field in an object. This
would distinguish the main Title of a book from its alternate Title.

whereas:

0. a "subclass" adds behaviour (and/or fields in languages that require
their declaration) to a class, as a separate entity from the superclass,
but dependent on the superclass.



Which makes me doubt whether the example you are giving is applicable in
real programs (or: whether it is good practice to apply it), and in turn,
whether your point is valid.



(PS: and similarly anything involving Circle<Ellipse, unless a situation
is given in which a Circle subclass makes sense)

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju