On 23 October 2010 17:13, Schwab,Wilhelm K <[email protected]> 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: [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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
