On 23 October 2010 14:33, Stéphane Ducasse <[email protected]> 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: [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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
