If I understand you, you took things normally stored in instance variables, and (redundantly?) stored them as properties, right?
________________________________________ From: [email protected] [[email protected]] On Behalf Of Igor Stasenko [[email protected]] Sent: Saturday, October 23, 2010 10:47 PM To: [email protected] Subject: Re: [Pharo-project] some patterns I would like to **kill** On 23 October 2010 21:47, Schwab,Wilhelm K <[email protected]> wrote: > Hey, I want some credit here - for coming to Squeak's possible defense :) > > All I am saying is that there is a possible space/speed tradeoff with a > twist. There was a fair amount written about these decisions, which is why I > know anything at all about them. Adding an instance variable for a rarely > used sub-morph of a widely-instantiated morph might be an opportunity to fail > to learn from history. Most likely, the patterns Stef has noticed are simply > mis-uses of sparse storage. The best way to proceed would be to find an > example of it that has many instances in the image, profile, fix, and profile > again to see if the fix hurts performance (or perhaps helps it). The usual > caveats about benchmarking being really hard to do well apply, of course. > I did some experiment(s) with Morphic, placing many morph aspects into properties dictioary (such as color, border, borderwidth etc), and these values are used in rendering all the time. And i didn't noticed heavy speed degradation. > Bill > > > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Igor Stasenko > [[email protected]] > Sent: Saturday, October 23, 2010 11:00 AM > To: [email protected] > Subject: Re: [Pharo-project] some patterns I would like to **kill** > > 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 > > _______________________________________________ > 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
