On Sunday 06 June 2004 10:19, Gavin Sinclair wrote:
> On Monday, June 7, 2004, 2:42:06 AM, Sean wrote:
> > A type would say something like:
> >
> > All hashes have a method called each_pair that takes no parameters and
> > calls the given block once for each key/value pair the hash contains.
> >
> > Now, for brevity, consider that the entire type description for a Hash. 
> > What we have now is a "hash type."  The Hash class itself can still
> > change it's methods, including its each_pair method, but if it ever
> > strays from the description of a hash type, it is no longer a hash type.
> >
> > If Hash tagged itself as complying with the "hash type" you could depend
> > on certain methods doing certain things and taking a certain number of
> > parameters.
>
> What if a class tags itself as a "hash type" but an instance of it
> redefines a method in a way that contradicts that type?

Derivatives should, by default, inherit the type tag.  If the developer really 
diverges from the purpose of a hash, but derives from the Hash class, that's 
his gun and his foot he's aiming at.  I don't care about developers doing 
goofy things.  Ruby is all about being able to do goofy things.

> I'm not being alarmist, but your messages have shown a great deal of
> concern for knowing that an object does what it advertises.  How do
> you see the above scenario, then?

I see it as: don't be afraid of the consequences of inheriting a class that is 
tagged as implementing an interface, and then changing your new class to do 
something completely different.  Just remove the tag, or leave it there and 
let mayhem ensue.  Ruby is generally one giant gun aimed at your foot the 
moment you write your first line of code, capable of pretending to do lots of 
things when it can't and doing things without claiming that it can, so I 
don't see why heavy constraints should be put in just because of interface 
identification.

	Sean O'Dell