Re: [Pharo-dev] Killing respondsTo:
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? 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.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
Re: [Pharo-dev] Killing respondsTo:
On 14 May 2013, at 17:35, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Something like self performIfExists: #blah would reduce the noise a lot :) Then in this methods, we do what we want ^^ IMHO, lots of #respondsTo: or #isKindOf: are a sign of bad code, bad design. But in a number of key places a #performIfExists: can be very helpful and even necessary. Sven Ben On May 14, 2013, at 5:32 PM, Frank Shearar frank.shea...@gmail.com wrote: 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
Re: [Pharo-dev] Killing respondsTo:
Then you will have [ receiver strangeMessage ] on: Error do: [ receiver otherMessage on: Error do: [ self defaultFallback ] ] ^^ Ben On May 14, 2013, at 10:22 PM, stephane ducasse stephane.duca...@free.fr wrote: agrh I would vote against it because slowly we would get this plague in the system. Stef On May 14, 2013, at 5:35 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Something like self performIfExists: #blah would reduce the noise a lot :) Then in this methods, we do what we want ^^ Ben On May 14, 2013, at 5:32 PM, Frank Shearar frank.shea...@gmail.com wrote: 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
Re: [Pharo-dev] Killing respondsTo:
+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.
Re: [Pharo-dev] Killing respondsTo:
You do not have that because *people* use respondsTo: ^^ My point was that if coder what to be lazy, and do not care about code, then you can always find a dirty hack-around This one kind of simulate a receiver respondsTo: #strangeMessage ifTrue: [ receiver strangeMessage ] ifFalse: [ .. ] … Ben On May 14, 2013, at 10:32 PM, stephane ducasse stephane.duca...@free.fr wrote: On May 14, 2013, at 10:25 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Then you will have [ receiver strangeMessage ] on: Error do: [ receiver otherMessage on: Error do: [ self defaultFallback ] ] can you show me real examples? Because in 15 years of Smalltaking non trivial program (but may be not complex enough) I never needed that. The few times where I did somethng like that was to load broken and incomplete Squeak code lazily in VisualWorks. But it was a real deep and fun hack Stef
