From: Sean O'Dell <sean@...>
Date: 2003-11-20T07:55:16+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata  about attribute types)

Check Ruby Garden for my RCR on this subject.  Comments follow, James.

On Wednesday 19 November 2003 02:33 pm, Weirich, James wrote:
> Sean O'Dell writes:
> > > Actually, it tells you exactly.  If a class inherits from String, you
>
> know it
>
> > > has all the methods String does, and you know exactly what parameters
>
> they
>
> Charles Hixson writes:
> > No, you don't know that at all.  It's a reasonable
> > presumption, but any, or all, or the methods that you think
> > are there might have been overridden.  And might do something
> > totally different.  And this may be for either a good reason
> > or a silly reason.
>
> Several people have said this, and although true, this is not my main
> concern and if people make an object non-LSP compliant, then they get what
> they deserve.

This is my feeling as well.  It is, after all, The Ruby Way.  At least right 
now it is.

> However, my concern is the insistence that only those things that have
> String in their ancestry can have string like behavior and can be passed to
> functions expecting a string like object.
>
> And this is what I thought Sean was saying (i.e. advocating ancestry
> checks).

No, but close.  I believe IF a class inherits from another class, it can 
automatically be thought to implement the base class' interface.  However, I 
think the declaration of an interface can be made without inheritance.

> I now think what Sean is some way of "marking" a class to indicate that in
> implements a particular protocol.  That marking could be through
> inheritance, but could also be done by some alternate mechanism.

Yes!  That's what I mean to say.  But also with that, the assumption that 
classes that inherit from other classes inherit their interface.  But that's 
only one way to declare an object implements an interface.

> This (IMHO) is not nearly as onerous as ancestor checking.  But I'm not
> convinced of its utility yet.  I'll have to think about this.
>
> Sean, did I capture your thoughts accurately?  Or am I still missing
> something.

Yeah, pretty accurately.  My RCR, I think, makes it clearer.  It's really 
based on a bunch of things I've read here in this newsgroup; it's not really 
my idea.  More of a conglomeration of ideas.  The problem, I think, is that I 
jumped in with my thoughts and started off by wielding all the wrong 
terminology.  I should have started fresh with a new line of discussion 
instead of pouncing in the middle of what was being said at the time.

One thing about what I propose is, except for the syntactic sugar for 
parameters, which would be something only Matz could really implement (and I 
assume it would be a bit of a pain), the rest of it is something that would 
be super-easy to implement.  In fact, it's probably a 10-minute coding 
project.  But I think it would die the death of obscurity if it weren't 
built-in.  Not many people would use it, but for those of us who are using 
Ruby for some pretty sizable projects, they would be infinitely valuable.

	Sean O'Dell