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

On Wednesday 19 November 2003 01:01 pm, Chad Fowler wrote:
> On Thu, 20 Nov 2003, Sean O'Dell wrote:
>
> # On Wednesday 19 November 2003 11:46 am, Chad Fowler wrote:
> # > On Thu, 20 Nov 2003, Sean O'Dell wrote:
> # >
> # > # I'm clear on the subject of dynamic typing, and I'm not an advocate
> for # > static # typing.  Being a strong advocate for one or the other is
> foolish, # > in my # opinion.  Both are useful, and both can be employed
> here, so I BEG # > you to # please employ SOME form of built-in interface
> checking.  Having # > absolutely NO # mechanism leaves people who need to
> check for certain # > methods and parameters # hanging in the wind.
> # > #
> # >
> # > If you really need something that bad, how about respond_to?  If you
> need # > something more robust, then there's types.rb by Eivind Eklund. #
> # Because something of this nature should be built-in.
>
> ...in your minoority opinion.

I'm in the minority of people who are here to speak out FOR some form of type 
checking.  There are few here who argue my side of the issue.  My feeling is, 
so many here are so strongly against it that they don't bother even posting 
here.

> # It's faster when written
> # in C and doesn't have to be dynamically loaded via "require."  I also
> don't # believe type checking is something that there should be competing
> libraries # for.
>
> Why not?  By the way, I think types.rb is the only library that actually
> *does* type checking in the accurate ruby sense.

Already answered elsewhere.

> # Also, respond_to? doesn't say anything about what a method does or what
> # parameters it takes.  Checking for an implemented interface declares all
> of # that.
>
> As demonstrated previously in this thread, class and/or module inheritance
> checking *doesn't* give you any info about what a method does or what
> parameters it takes.

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 
take.  The class developer can radicially modify those methods, and yes the 
class no longer conforms to the String interface, but that's just one example 
of what humans do to circumvent an enforcement mechanism.  It happens; I'm 
not concerned with what happens when people deliberately break the interface 
implementation.

But as I've said, "interface checking" is not checking ancestry.  Ancestry is 
just one way a class declares that it implements an interface.  It can just 
as easily make that declaration without inheriting anything.  I was thinking 
perhaps an "interface" keyword would work to make the declaration.  The class 
would then be free to implement as much of the interface as it wants to, or 
none of it.  The declaration is just a declaration, not a guarantee or 
inheritance.

	Sean O'Dell