gabriele renzi wrote:
>>Let's say I want to implement interfaces using classes (so I can do 
>>interface checking with the simple Object#kind_of?). There will be 
>>components (which will also be classes). A component can implement one 
>>or more interfaces. Method names from different interfaces might clash 
>>(e.g. IFoo#quack vs IBar#quack) and we need to be able to choose which 
>>interface we want to use from a component.
> 
> take a look at PyProtocols,
> http://peak.telecommunity.com/PyProtocols.html
> 
> may be of interest to you. Imo, it's a complex solution to a complex
> problem, I'd prefer less general and easyer. 

I took a look at PEAK & PyProtocols a few weeks ago. I've also seen 
Zope3's component architecture some months ago. I heard they will 
somehow merge their interface/component architecture.

To tell you the truth, I don't like the way they do it. IIRC, Zope3 
implements interface as a normal object (instead of a class). Also their 
notion of a 'component' is not like what I have in mind (which is more 
like COM's or CORBA's component). Zope's component is more like a 
'component instance' instead.

But I agree with you about simpler solution. Interfaces (at least in 
Java) are basically another hierarchy of class-like/type-like things, 
separate from the class hierarchy.  We just need to define interfaces 
and tag classes ("components") with them. Classes are the entity closest 
to interfaces, so I tend to define interface as a Ruby class.

-- 
dave