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

"Sean O'Dell" <sean@celsoft.com> wrote:
> 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.

I don't think they need to be checked off. Couldn't the "end" which
finishes the class definition (or part-thereof) signal a single check?
It might be a more complex check and hence the same overall efficiency,
or it might be better. *shrug*

I'm trying not to think *too* hard about efficiency. Premature
optimization and all that...


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

Yes.


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

Well, matz in another post says he's against implicit interface
definition through class definitions.

Perhaps an additional line at the end of the class would be a
compromise?

class Foo
  # ...
end

interface IFoo from class Foo

Or something. In fact, I could probably do this in Ruby 1 by doing this:

class Foo
  # ...

  define_interface(:IFoo)
end


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

This is where the use of interfaces really beats, I think, use of
respond_to?. Interfaces provide context.

I think I might have a go at implementing my proposal (or
over-simplification as the case may be) in Ruby 1.8 because it's a
hybrid between Ruby 1 and your proposal. Then I could observe how the
interfaces get broken and fixed with the removal and addition of
methods. :) I can also include an explicit method call to check a set of
parameters implement a set of interfaces, so you'd have optional
parameter type (or rather interface) checking too.

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