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