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

On Thursday 20 November 2003 07:27 pm, Greg McIntyre wrote:
> "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...

Internally, though, Ruby would store the interface information in its own way.  
When a class declared that it implements it, as methods are added to the 
class which fulfill the interface requirements, they would be checked off 
until the last one, then a flag would be raised for the class to indicate 
that it fully implements the interface.

It would all be done at class-load-time.

> 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".

No, the definition is written once and then methods refer to the interface by 
its name only.

> 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. :-)

Interfaces usually imply a purpose, and since an object usually has multiple 
methods, all of which do something different, but for one general purpose, 
wrapping the purpose up as an interface is convenient.

	Sean O'Dell