From: Greg McIntyre <greg@...>
Date: 2003-11-21T12:27:16+09:00
Subject: Re: New Type Checking System Idea

"Sean O'Dell" <sean@celsoft.com> wrote:
> In your modification, you were building these arrays every time, and
> then for conformance, I assume Ruby would have to do an array-to-array
> comparison to determine compliance.  It's sort of the same thing, but
> since that would happen constantly at run-time, I think it's probably
> more overhead than we're aiming for.  But yeah, it's definitely the
> same thing.

Ah, that wasn't clear in my email. Ruby must do something like that
already because at any stage you can get a list of a classes's public
instance methods. I was just putting it in a comment for clarity. There
were no checks between the methods, just at the end of the class
definition (or partial class definition, if it spans multiple files), to
assert whether or not what's there so far implements the promised
interfaces.

I think that's necessary though because it can't build a list of
required methods at the start based upon the interfaces promised and
then slowly destroy it, then check it's empty at the end, because the
list of "unfulfilled methods" may grow again and I don't see how that
would happen if you destroyed the list of interface methods needed...

And just to clarify, what I meant by "too much work" was that when you
define a class, you implicity define its interface (although this
interface in Ruby 1 only has method names and arities), so I wouldn't
want to have to define a class's interface separately in order to say
"ensure this object implements this _class's_ interface".

So it's like your proposal, only with an implicit shortcut. You could
either define interfaces by defining classes and referring to their
interfaces (in that respect a Class object "has" an Interface object),
or define standalone interfaces unrelated to classes and assert
that objects implement them at run-time, or include them in classes to
prevent forgetfulness when implementing (see Enumerable's problem with
#each). :-)

I think that's what you meant, I just wanted to be clear about it.

However I'm still thinking about what Geoff Youngs suggested about
uniquely identifying the purpose of components in an interface. With
fine-grained respond_to? checking, you wouldn't know what :pants really
was for, it could mean several things. Whereas if this were part of an
interface, would that interface provide enough context to identify its
purpose? Is it possible to uniquely identify a method's purpose given
its context in a well-written set of interfaces? My brain's fizzled and
I need time to think about it. It's probably not perfect but it's
good, I think. :-)

-- 
Greg McIntyre ======[ greg@puyo.cjb.net ]===[ http://puyo.cjb.net ]===