Like I say, _in this case_ just implement a common method that everything speaks. And if you follow that all the time you get crazy nonsense spamming all your objects. Or you can say "if this thing's like a Stream, do this; if it's like a Collection, do that". And in that case, basing that decision on inheritance is a fail. As always, it's a matter of judgement & taste. frank On 14 May 2013 21:27, stephane ducasse <stephane.ducasse@free.fr> wrote:
why do we want to introduce a bad slow type system on certain single place? Why a UI element would have to check that a given instance can do something while we never ever do it in any other places.
if we have a button and its label should be able to answer the message enabled then we display the button and send the message enabled. If it crashes then this is the programmer' fault. He should provide an object that responds to enabled but we do not test it.
And we should have nice polymorphic objects and not string and nil and color why not array with hexa decimal colors?
Being reasonable programmers and not kids wanted to plug anything anyhow is the way to build nice system (and polymorphic objects).
Stef
On 14 May 2013 16:21, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
I'm in favor killing all the respondsTo:
acceptTextMorphs "Accept any text morphs except for those that have no edits."
self allMorphs do: [:p | ((p respondsTo: #accept) and: [ (p respondsTo: #hasUnacceptedEdits) and: [ p hasUnacceptedEdits]]) ifTrue: [p accept]]
They're a step up from #isKindOf:. It looks like you need is something that says "does this object respond to a particular set of messages (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! :) )
But in this particular case the solution looks like making a #insertADecentNameHere that particular classes of things can implement as "^ self hasUnacceptedEdits ifTrue: [self accept]"
frank