+1 Doru
On May 14, 2013, at 10:27 PM, 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 >> > > -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."
