Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

On Friday 21 November 2003 12:12 am, Thien Vuong wrote:
> Sean O'Dell wrote:
> > On Thursday 20 November 2003 07:58 pm, Yukihiro Matsumoto wrote:
> >>At least I need to take time to sit down and read your article
> >>carefully first.
> >
> > This is, I think, the clearest I can make the new proposal tonight:
> >
> > http://www.rubygarden.org/ruby?InterfaceContracts
> >
> > Perhaps tomorrow I can clean it up some more, when my eyes don't hurt as
> > much, and after Ziegler points out how wrong it is and how pointless even
> > trying is and how it's all just pointy-haired twaddle to be immediately
> > made obsolete by an eval statement.
> >
> > 	Sean O'Dell
>
> I read it over a bit and have a few comments
>
> - Rather have the method definition stay as is (no addition of type
> declaration).  Interface should be an optional enhancement - take a
> class, add a interface (hopefully short) section, and we have what we
> need - no fuss (or in Ruby, reopen an
> existing class, ...).  It may be more work to allow interface to be
> added "after" the method have been defined though.

This is entirely possible:

I agree there is no need to declare any type declarations in the method 
itself, and I meant to eliminate those from the example code in the 
"interface implementation" section where the class was defined.  I was tired.

It's no more work really to add the interface to an existing class.  It's all 
just a matter of comparing the interface table to the method definition.  
There's very little difference between catching "method added" calls and 
iterating through all the methods.

> - Rather not have the return type declaration.  With dynamic language, I
> don't know if this could be done without runtime checkin.  Also, the
> check, I think, would also need to be done at the object receiver end
> (i.e. calling class) and this would involves runtime checkin with the
> cost to be born by user of object.

Run-time checking would have to be done to match parameter types (interface 
contracts) anyway.  It's probably not a big difference to also check the 
return type as well.

> BTW, thanks much for taking the heat for trying to expose this issue.
> Don't know where this will lead but it is much better than people get
> exasperated and quietly leave.

It's not a problem at all.  The thinkers got separated from the agitators 
pretty quickly, and I'm dealing with the agitators in my own way.  Once I 
know someone is just being negative and crude, it's pretty easy to whip them 
up a batch of their own medicine.

> I do feel, however, that having interface fully separated from class put
> an onus on the use of interface (as personally I mostly design the
> object structure through the interface -i.e. user of objects should not
> have to care/deal with class - only interfaces).  Class is only a
> convenient expression to support code reuseability through inheritance
> and polymorphism.  But it is also a convenient way of describe
> interface.

I agree with this entirely, but I also see it the other way around.  The 
StringIO is the standard case example.  If a method requires a parameter to 
be of type IO, you wouldn't be able to pass a type StringIO because StringIO 
is not derived from IO, it merely implements the same interface that IO does.  
Thus the need to separate IO.

Although, this could also be settled through virtual classes that define the 
interface, and StringIO could be changed to inherit it.  I am not sure why 
that is not a valid option because it's the sort of practice I'm used to, but 
I'm sure there's a reason for it.

Maybe someone should say why, exactly, StringIO doesn't derive from a virtual 
base IO class?

> Syntactic sugar (simplicity, style) is a desirable feature of Ruby, and
> making it it inconvenient to use will turn people off from using
> and we'll be right back to using the same stuff as where we started.

Agreed.  I think possible syntax sugars will become apparent as this sword is 
hammered out.

	Sean O'Dell