On 14 May 2013 21:27, stephane ducasse <[email protected]> wrote: > why do we want to introduce a bad slow type system on certain single place?
I just realised. You realise of course that reifying the set of messages you expect something to implement - a protocol - is exactly as slow a type system as isCollection, isMorph, ...? Only reifying such a protocol would tell you what a stream actually _is_, what its minimal interface is, without you having to guess that you need next:, atEnd, and whatever else. So it's not as bad a type system! frank > 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]> 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 >> > >
