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

On Wednesday 19 November 2003 11:14 am, Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: "stereotyping" (was: Re: Strong Typing (Re: Managing
> metadata about attribute types) )"
>
>     on 03/11/20, "Sean O'Dell" <sean@celsoft.com> writes:
> |Listen, I don't mean to be obtuse, but declaring Ruby's flexibility is not
> | a guarantee of flexibility.  It's flexible until a library requires
> | certain methods and parameters.  Then you're stuck.  It's better to get a
> | nice, descriptive message like "your object does not conform to the
> | :memorymap interface" than to get a message that says "in line 45,289 of
> | a file you know nothing about in the middle of a bunch of code you didn't
> | write, a call was made to some object whose name you have to trace to
> | find out where it came from and that call didn't have the right number of
> | parameters.  Figure it out for yourself, bubba."
>
> I don't mean "type checking is bad", but "type checking based on class
> inheritance hierarchy is bad", and we don't have any other better type
> checking schema in Ruby (yet).

No, type checking based on class inheritance (and mix-ins) is completely fine.  
Just think of the checking not as "type enforcement" but as "interface 
declaration."

A class is a declaration which says "I do this."  The class can change, and it 
can be extended, but it's just the statement that matters.  The programmers 
just needs to know.  No language can do anything with an object by itself, 
only the programmer decides why an object must be of a certain type.  Just 
having a mechanism to enforce that an object has a certain class in its 
hierarchy says "I do this."  So when a programmer makes a mistake and passes 
an object that can't be used by a method, they get an error message that says 
"your object does not do what I want."

> |See what I'm getting at?  Your flexibility is already gone at this point. 
> | I'm not advocating taking away any more.  I'm just advocating a mechanism
> | for reporting these incompatibilities, so when you are hit with this
> | problem, you can very quickly assess what went wrong and make an
> | adjustment.
>
> It's good to have the mechanism like that, I agree, even I put the
> feature in my latest slides.  But there's still long way to design and
> implement it efficiently, if I am right.

Take the easy road.  Just go with an "interface declaration" mechanism.  Just 
enforce that objects are descended from certain classes, or were mixed-in.  
If a programmer goes out of his way to change the object radically, fine, it 
will break just like it breaks now.  No harm done.  The alternative would be 
to enforce that all expected methods and parameters are present in a precise 
form, and that would be insanely strict.

It's a very open-ended solution.  Some people won't use it at all because they 
don't have any need for typing.  Those people will be unaffected.  Some 
people will need it occassionally, probably library developers mostly.  Those 
people will have a good way to warn developers when they are passing in the 
wrong objects to the library.  Sometimes objects will change radically, and 
they won't conform to the interface they declare themselves to conform to.  
Oh well.  That's how Ruby is now.  The error message will come from deep 
inside the library and will be ugly.  Oh well.  Too bad for the developer who 
overrode the method and changed the order/number of parameters.  My advice 
there is: don't do that.

	Sean O'Dell