[Pharo-project] some patterns I would like to **kill**

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sat Oct 23 10:13:39 EDT 2010


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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse at inria.fr]
Sent: Saturday, October 23, 2010 7:33 AM
To: Pharo-project at 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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




More information about the Pharo-dev mailing list