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]] :) And there are too many Smalltalk references in the system
Me too, do you have free the friday afternoon to sprint on them? :D On Tue, May 14, 2013 at 5:21 PM, 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]]
:)
And there are too many Smalltalk references in the system
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
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.shearar@gmail.com> wrote:
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
On 14 May 2013, at 17:35, Benjamin <benjamin.vanryseghem.pharo@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.shearar@gmail.com> wrote:
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
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.pharo@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.shearar@gmail.com> wrote:
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
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.ducasse@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.pharo@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.shearar@gmail.com> wrote:
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
On May 14, 2013, at 10:25 PM, Benjamin <benjamin.vanryseghem.pharo@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
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.ducasse@free.fr> wrote:
On May 14, 2013, at 10:25 PM, Benjamin <benjamin.vanryseghem.pharo@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
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.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
+1 Doru On May 14, 2013, at 10:27 PM, stephane ducasse <stephane.ducasse@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.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
-- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."
Like I say, _in this case_ just implement a common method that everything speaks. And if you follow that all the time you get crazy nonsense spamming all your objects. Or you can say "if this thing's like a Stream, do this; if it's like a Collection, do that". And in that case, basing that decision on inheritance is a fail. As always, it's a matter of judgement & taste. frank 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? 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
... snip Being reasonable programmers and not kids wanted to plug anything anyhow is the way to build nice system (and polymorphic objects).
Yes, absolutely, but that is totally independent of whether reflective capabilities still exist in the system. Hey, maybe after #respondsTo: is removed, one of the kids will fix that method: self allMorphs do: [:p | ((p class methodDictionary includesKey: #accept) and: [ (p class methodDictionary includesKey: #hasUnacceptedEdits) and: [ p hasUnacceptedEdits]]) ifTrue: [p accept]] ;-)
Yes, absolutely, but that is totally independent of whether reflective capabilities still exist in the system.
Hey, maybe after #respondsTo: is removed, one of the kids will fix that method:
self allMorphs do: [:p | ((p class methodDictionary includesKey: #accept) and: [ (p class methodDictionary includesKey: #hasUnacceptedEdits) and: [ p hasUnacceptedEdits]]) ifTrue: [p accept]]
What we see here is the fact that we use submorphs as a general container and query it we avoid bookkeeping of dedicated containers pointing for example to textMorphs. So we trade bookkeeping for runtime checks and on top of that we also get complex Morph API (but that part can be ok I'm not convinced that all the morphs should understand accept). We do not do that when we build seaside application. We use instance variable to point to the right set of objects. I would really like to know what is the real cost of having this extra list of morph that can understand the accept messages. How many times in the same morph you may have multiple containers for dedicated morphs in addition to the submorphs ones. Stef
+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 <stephane.ducasse@inria.fr<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
+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 <stephane.ducasse@inria.fr<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
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
One of the most innovative concepts Smalltalk brought as a language in the 1970's is the notion of sending messages. I don't think removing #respondsTo: will help cure bad code. For a system as capable as Pharo, to go far with it, I just don't think there's any way around the need for students to /learn/ the best practices and not use unnecessary reflection in apps. But /app-building/ frameworks often need to be able to reflect on the code model. On Tue, May 14, 2013 at 10:21 AM, 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]]
:)
And there are too many Smalltalk references in the system
On May 14, 2013, at 7:05 PM, Chris Muller <asqueaker@gmail.com> wrote:
One of the most innovative concepts Smalltalk brought as a language in the 1970's is the notion of sending messages. I don't think removing #respondsTo: will help cure bad code.
It will It is like isKindOf: Signs of non polymorphic code and/or unexpected contracts.
For a system as capable as Pharo, to go far with it, I just don't think there's any way around the need for students to /learn/ the best practices and not use unnecessary reflection in apps. But /app-building/ frameworks often need to be able to reflect on the code model.
well⦠It is a sign of non polymorphic design. And in the industrial systems we are building we do not want that too.
On Tue, May 14, 2013 at 10:21 AM, 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]]
:)
And there are too many Smalltalk references in the system
participants (9)
-
Benjamin -
Chris Muller -
Frank Shearar -
Guillermo Polito -
Otto Behrens -
stephane ducasse -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba