From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-11-21T19:28:33+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

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

Actually it's rather an application of the adapter pattern, which is an
interface problem and which could benefit from support in interface
declaration. But my problem rather lies in the fact that two libraries
both expect an object to have a method with a certain name - but the same
for both - but they expect different behavior from it. You can always
rename your own methods, but not those that a library expects. (Though you
can "adapt" those a library offers through something like aliasing).

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

My point is just that the wolves will pick on this because it decreases
flexibility in the sense that any method which expects an object
implementing a certain interface can't be passed such a proxy. If it's
just your own code, you can just decide not to use the interface (which is
basically what you say above, right? Or only use part of it), but anyone
using your interfaces in a library API would restrict the flexibility for
the users. Basically implementing an interface is saying that you are duck
typing, but the check doesn't manage all of duck typing.

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

Well, just saying it would be nice to think of this possibility up front,
that it's possible and easy to do. I'm sure Matz is a much better
programmer than anyone of us, but not all is easily done.

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

OK, this is where I don't agree with you. If you don't allow refining the
granularity (which superinterfacing is supposed to do), you'll always end
up being less flexible than duck typing as it is now. This has nothing to
do with poor design. A good design is flexible, maintainable, adaptable,
but it can't provide for all future needs. Can you guarantee that if you
write an interface, that it's the smallest useable subset of
functionality?

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

I will. Suppose someone design a library with Input and Output as provided
interfaces. Then classes will emerge that implement these interfaces,
right. The separation in Input and Output is based on the functionality of
the library, logically, right? When I use this library, and I would need
only an interface that only requires a subset of say the Input interface.
This is possible, right? I have several options. Either I create my own
interface with a subset of the methods of the Input interface, but then
any class implementing this Input interface can't be passed as something
implementing your interface, or at least not as such, while duck typing
allows for this. If you allow for superinterfacing (i.e., defining a
subset of methods in a separate interface), you have this flexibility
automatically.

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

I know, I've been thinking about this as well when this thread started and
I am convinced as well that it isn't very hard to pull off.

Peter