From: Sean O'Dell <sean@...>
Date: 2003-11-21T10:21:14+09:00
Subject: Re: "stereotyping"

On Thursday 20 November 2003 05:02 pm, Martin DeMello wrote:
> Sean O'Dell <sean@celsoft.com> wrote:
> > something in Ruby like usual, then as a project started to get larger and
> > more complicated, or as people were added to the project who might not
> > fully understand all your classes, wouldn't it be nice to say "okay kids,
> > before you go muddying up this project, here's a couple rules for you. 
> > never pass anything but this type here.  and this type here."  So except
> > for the places where you think you ought to provide a little guidance,
> > leave the rest of it wide open as usual.
>
> I keep getting hung up on this point. Are you proposing an entire
> parallel type hierarchy based on interfaces, or are you going to let
> normal ruby 'types' be used as arguments? And if the latter, what's to
> define those types?

The syntax of the interface description isn't really that important; it's 
something that can be bantered around for awhile, I just showed one possible 
way to define them.  But yes, I would like to see class and interface as two 
separate things, in parallel, but not perfectly synchronized, at least in 
concept (although for eloquence, they could be joined syntactically).  The 
idea is not to constrain classes themselves except to require them to adhere 
to the interfaces they proclaim to implement.

Normal Ruby types are so dynamic, I don't think you could ever base type 
checking on them.  Not without excessive runtime overhead.  I could be wrong, 
but that just seems like such a dark, ugly alleyway.  Types, as required by 
method parameters in my proposal, would be interface names, and objects 
passed to those methods must completely fulfill the interface required.

	Sean