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

On Thursday 20 November 2003 05:51 pm, Peter wrote:
>
[...highly informative paragraph removed for brevity...]
>

I am not sure exactly how Haskell works, but it sounds like perhaps 
fulfillment could occur through a form of aliasing, although calls could 
still be made to the method required by its original name.  Calls doing that 
would actually route through the aliased method.  Since this only involves 
the interface mechanism, and would be just another method to Ruby, this could 
work, sure.

It could look like:

class AnyClass
  def method(parameters) implements someothermethod
end

... which would allow someothermethod to be fulfilled in the interface 
requirement, but the method would actually be called method.  You could call 
either and get the same method.  Until the method was subbed later on by its 
real name, in which case method would just be a method (and would still 
exist).

> Having used the occasion to put forth yet another stupid idea, I'll get to
> your proposal... Momentarily you can't work the ObjectProxy below with
> your technique, or anything that includes a method_missing technique. I

Interfaces allow that, but wouldn't be able to provide for it.  You could 
certainly still handle method_missing calls for methods that are outside the 
scope of an interface because an object would only need to fulfill an 
interface, not be strictly bounded by it.  I doubt we could create an 
interface mechanism that actually made use of method_missing, though.  I 
think when it comes to interfaces, things get a little bit strict.  But the 
freedom is still there to work outside of them.  If a class can't implement a 
method without handling it through a call to method_missing, I think we have 
to say that method cannot fulfill an interface.

> Another thing; since methods can be removed and added, maybe it's
> interesting to also be able to add or remove the notification that you
> intend to implement an interface. As such, no dynamism is lost there. But
> it's an extra complication :-(

I think when it comes down to the nuts and bolts of it, those sorts of things 
are cool ideas to patch in down the road.  I think the basics of it will 
work, and this sort of thing will crop up now and again, but Matz or someone 
would be able to zip in a patch to do that pretty easily.

> Last thing (unless I come up with something else before I send this mail);
> you should probably also provide a way of declaring superinterfaces and
> subinterfaces. Suppose someone provides an interface InputOutput which
> provides methods for inputting and outputting (what else?). If some method

There are two ways this is partially covered:

One, and I know this is the "not my job" answer: interfaces should be 
well-defined enough to separate Input from Output to begin with.  I think 
with poorly designed interfaces, you're going to have trouble.

Two, interfaces can be subbed in my proposal, so you could subclass an IO 
string interface from a base IO interface.

But as to superclassing, since the original interface designer lumped Input 
and Output into one interface, what you are really talking about is bypassing 
the interface requirements that methods might have.  Instead of looking at it 
as superclassing an interface, look at it as shoving any old object past a 
requirement.  I think there should be a mechanism for that as well.  
Flexibility should always be paramount.

Unless I misunderstood your use of superclassing the interface.  Correct 
please if I'm wrong.

> BTW, I really admire you for still being here after all the heat :-)

I wouldn't be if I thought perhaps I couldn't tackle the problem.  I've 
written several different script language incarnations, and I know the trick 
is to keep the back-end as simple as possible.  No matter how cool any system 
might be on paper, if it's hard enough on the back-end, it will perform 
poorly and break a lot.  I'm trying to keep Matz' workload in the forefront 
of my mind while working through this.

	Sean O'Dell