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?
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 <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