On Oct 23, 2010, at 1:58 PM, Igor Stasenko wrote: > 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>
I like your sarcasm, we are all in sync on that Open a 3.8 or 3.9 and check findA: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
