+1 On Tuesday, 14 May 2013, stephane ducasse 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 > > <[email protected]<javascript:;>> > 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.FinWorks.biz +27 82 809 2375
