From: Sean O'Dell <sean@...>
Date: 2003-11-21T09:54:08+09:00
Subject: Re: New Type Checking System Idea

On Thursday 20 November 2003 04:37 pm, Greg McIntyre wrote:
> I like your idea, Sean, but it's too much effort! If it is onerous then
> it won't be used. Perhaps if we based it upon method name and arity
> (essentially replacing a bunch of respond_to?() calls with arity
> checks added in as a bonus). This is because it requires no extra effort
> on the programmer's part, so it fits into the existing Ruby syntax.

Very funny.  =)

Actually, I sort of meant my proposal to require a very minimal effort for 
both sides.  On Matz' end (save for syntax sugar) it's not a heck of a lot to 
code, and it doesn't screech hard against the existing code (at least not 
from what I've seen, could be wrong), and on our side it's just a short block 
of interface description to write.  It really couldn't get a heck of a lot 
easier except to just not do it, or to do some sort of interface id tagging 
thing like my first proposal, where no enforcement was performed at all.

> I took your code and rewrote it a bit...

Ha.  Ha.  =)

It looks like too much happens at run-time, always checking and querying for 
certain methods, etc.  Also, the concept of a whole interface, rather than 
querying for a set of required methods, I always think is easier to grasp.

I mean, there will always be respond_to? and for those people who see no use 
in interface checking, they can, as always, keep just asking respond_to? or 
not asking anything at all.  Your changes seemed to be sort of a souped-up 
respond_to? engine.

Not to mention, no information about required parameter types.

My feeling is, a short run of overhead at compile-time is better than constant 
overhead at run-time.  My proposal does all the interface fulfillment 
checking at compile-time, then conformance checks are done with a simple flag 
test internally.

	Sean O'Dell