Traits vs interfaces and a trivial idea (was Re: Future of smalltalk (was Re: election details *PLEASE READ*))

nicolas cellier ncellier at ifrance.com
Fri Feb 23 21:21:23 UTC 2007


Todd Blanchard a écrit :
> 
> On Feb 22, 2007, at 11:46 PM, Göran Krampe wrote:
>> As most people know a java interface is a "named bunch of messages" 
>> that a
>> class (or its superclasses of course) can declare it implements. But this
>> is early binding, right?
>>
>> I would be more interested in "late" binding where I could do:
>>
>>    someThingy respondsToProtocol: aProtocol
>>
>> ...where aProtocol is more or less just a bunch of selectors. The main
>> difference is of course that the class (or any of its superclasses) of
>> someThingy doesn't need to *declare* that it implements aProtocol - it
>> just has to actually do it. :)
>>
> 
> Get a mac. :-)
> 
> ObjectiveC  has Protocols (which I think were the inspiration for Java's 
> interfaces). Protocols can be formal (the class declares it implements a 
> protocol explicitly and the compiler whines if you leave something out) 
> or informal - you implement it but you don't declare it.
> 
> There is a lovely method in Cocoa conformsToProtocol: that does just 
> what you're asking.  I don't know how it works, but if I were to 
> implement such a thing in Squeak in a cheap and cheerful way - I would 
> reify a protocol as a class  and attache protocols to existing classes 
> much the way PoolDictionaries work now only instead of importing shared 
> constants, you are using it to enforce a set of methods.  How tools 
> prompt you to make sure you conform to the protocol you declare is an 
> exercise left to the implementer.
> 
> -Todd Blanchard
> 
> 
> 
> 
To be fast, you could rely on message sending

respondsToProtocol: aProtocol
	^self protocolChecker perform: aProtocol symbolicName

protoclChecker would answer an anonymous subclass of ProtocolChecker
ProtocolChecker would implement doesNotUnderstand as:
- checking if all methods of protocol are understood (needs a link back 
to associated class)
- implement a new method (aProtocol symbolicName) answering true or false

In order to inherit protocol, you would have to construct 
ProtocolChecker hierarchy like the metaclass one...

Adding or deleting in the methodDictionary would trigger a self 
protocolChecker flushCache in all subclasses.

The flushCache should also be invoked whenever a Protocol definition changes

And Andreas, please don't ask how this would mix with Traits!

Of course, this is overkill compared to a simple <Dictionary of Protocol>

Nicolas




More information about the Squeak-dev mailing list