Re: [Pharo-project] some patterns I would like to **kill**
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best. Stef On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. (self labelMorph respondsTo: #enabled:) ifTrue: [self labelMorph enabled: self enabled]. (self labelMorph respondsTo: #interactionState:) ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph "Answer the actual label morph."
self hasSubmorphs ifFalse: [^nil]. self firstSubmorph hasSubmorphs ifFalse: [^nil]. ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23 October 2010 14:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best.
<sarcasm> if morph having a random submorphs, inserted out of nowhere, just for fun to see what happen. then yes.. findA is userful, as well as respondsTo: </sarcasm> but if we are talking about specific morphs, like Pluggable and friends, who serving a certain purpose (building UI from spec), where no place for 'random', then this truly a bad design.
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. Â More defensive programming (aka masked bugs). Â Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Â Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. Â An instance variable could also cache stale information. Â Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. Â Â Â Â (self labelMorph respondsTo: #enabled:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph enabled: self enabled]. Â Â Â Â (self labelMorph respondsTo: #interactionState:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ Â Â Â Â self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph     "Answer the actual label morph."
    self hasSubmorphs ifFalse: [^nil].     self firstSubmorph hasSubmorphs ifFalse: [^nil].     ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Stef, Of course. But in terms of avoiding unintended consequences, just consider the points I raised. Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, October 23, 2010 7:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill** I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best. Stef On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. (self labelMorph respondsTo: #enabled:) ifTrue: [self labelMorph enabled: self enabled]. (self labelMorph respondsTo: #interactionState:) ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph "Answer the actual label morph."
self hasSubmorphs ifFalse: [^nil]. self firstSubmorph hasSubmorphs ifFalse: [^nil]. ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23 October 2010 17:13, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Of course. Â But in terms of avoiding unintended consequences, just consider the points I raised. Â Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used.
Well, one way or another you have to tame the complexity somehow. Be it extra instvar, or putting it into extensions doesn't changes the model's concept: you need a reference to some object which is responsible for some specific stuff.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, October 23, 2010 7:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill**
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best.
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. Â More defensive programming (aka masked bugs). Â Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Â Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. Â An instance variable could also cache stale information. Â Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. Â Â Â Â (self labelMorph respondsTo: #enabled:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph enabled: self enabled]. Â Â Â Â (self labelMorph respondsTo: #interactionState:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ Â Â Â Â self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph     "Answer the actual label morph."
    self hasSubmorphs ifFalse: [^nil].     self firstSubmorph hasSubmorphs ifFalse: [^nil].     ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Hey, I want some credit here - for coming to Squeak's possible defense :) All I am saying is that there is a possible space/speed tradeoff with a twist. There was a fair amount written about these decisions, which is why I know anything at all about them. Adding an instance variable for a rarely used sub-morph of a widely-instantiated morph might be an opportunity to fail to learn from history. Most likely, the patterns Stef has noticed are simply mis-uses of sparse storage. The best way to proceed would be to find an example of it that has many instances in the image, profile, fix, and profile again to see if the fix hurts performance (or perhaps helps it). The usual caveats about benchmarking being really hard to do well apply, of course. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Saturday, October 23, 2010 11:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill** On 23 October 2010 17:13, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Of course. But in terms of avoiding unintended consequences, just consider the points I raised. Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used.
Well, one way or another you have to tame the complexity somehow. Be it extra instvar, or putting it into extensions doesn't changes the model's concept: you need a reference to some object which is responsible for some specific stuff.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, October 23, 2010 7:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill**
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best.
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. (self labelMorph respondsTo: #enabled:) ifTrue: [self labelMorph enabled: self enabled]. (self labelMorph respondsTo: #interactionState:) ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph "Answer the actual label morph."
self hasSubmorphs ifFalse: [^nil]. self firstSubmorph hasSubmorphs ifFalse: [^nil]. ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23 October 2010 21:47, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hey, I want some credit here - for coming to Squeak's possible defense :)
All I am saying is that there is a possible space/speed tradeoff with a twist. Â There was a fair amount written about these decisions, which is why I know anything at all about them. Â Adding an instance variable for a rarely used sub-morph of a widely-instantiated morph might be an opportunity to fail to learn from history. Â Most likely, the patterns Stef has noticed are simply mis-uses of sparse storage. Â The best way to proceed would be to find an example of it that has many instances in the image, profile, fix, and profile again to see if the fix hurts performance (or perhaps helps it). Â The usual caveats about benchmarking being really hard to do well apply, of course.
I did some experiment(s) with Morphic, placing many morph aspects into properties dictioary (such as color, border, borderwidth etc), and these values are used in rendering all the time. And i didn't noticed heavy speed degradation.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Saturday, October 23, 2010 11:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill**
On 23 October 2010 17:13, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Of course. Â But in terms of avoiding unintended consequences, just consider the points I raised. Â Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used.
Well, one way or another you have to tame the complexity somehow. Be it extra instvar, or putting it into extensions doesn't changes the model's concept: you need a reference to some object which is responsible for some specific stuff.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, October 23, 2010 7:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill**
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best.
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. Â More defensive programming (aka masked bugs). Â Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Â Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. Â An instance variable could also cache stale information. Â Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. Â Â Â Â (self labelMorph respondsTo: #enabled:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph enabled: self enabled]. Â Â Â Â (self labelMorph respondsTo: #interactionState:) Â Â Â Â Â Â Â Â ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ Â Â Â Â self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph     "Answer the actual label morph."
    self hasSubmorphs ifFalse: [^nil].     self firstSubmorph hasSubmorphs ifFalse: [^nil].     ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
If I understand you, you took things normally stored in instance variables, and (redundantly?) stored them as properties, right? ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Saturday, October 23, 2010 10:47 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill** On 23 October 2010 21:47, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hey, I want some credit here - for coming to Squeak's possible defense :)
All I am saying is that there is a possible space/speed tradeoff with a twist. There was a fair amount written about these decisions, which is why I know anything at all about them. Adding an instance variable for a rarely used sub-morph of a widely-instantiated morph might be an opportunity to fail to learn from history. Most likely, the patterns Stef has noticed are simply mis-uses of sparse storage. The best way to proceed would be to find an example of it that has many instances in the image, profile, fix, and profile again to see if the fix hurts performance (or perhaps helps it). The usual caveats about benchmarking being really hard to do well apply, of course.
I did some experiment(s) with Morphic, placing many morph aspects into properties dictioary (such as color, border, borderwidth etc), and these values are used in rendering all the time. And i didn't noticed heavy speed degradation.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Saturday, October 23, 2010 11:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill**
On 23 October 2010 17:13, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Of course. But in terms of avoiding unintended consequences, just consider the points I raised. Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used.
Well, one way or another you have to tame the complexity somehow. Be it extra instvar, or putting it into extensions doesn't changes the model's concept: you need a reference to some object which is responsible for some specific stuff.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, October 23, 2010 7:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill**
I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best.
Stef
On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote:
Stef,
#respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak.
Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse@free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill**
Hi
I was reading Pluggable and friends I identified some patterns.
The respondsTo plague Examples:
color := self fillStyle asColor. (self labelMorph respondsTo: #enabled:) ifTrue: [self labelMorph enabled: self enabled]. (self labelMorph respondsTo: #interactionState:) ifTrue: [self labelMorph interactionState: self interactionState]
(self labelMorph respondsTo: #enabled:) ifTrue: [ self labelMorph enabled: aBoolean].
(self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]])
by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed.
Using submorphs to avoid one single inst var makes code quite ugly to read:
labelMorph "Answer the actual label morph."
self hasSubmorphs ifFalse: [^nil]. self firstSubmorph hasSubmorphs ifFalse: [^nil]. ^self firstSubmorph firstSubmorph
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Igor Stasenko -
Schwab,Wilhelm K -
Stéphane Ducasse