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