Hi Henry, Thanks for the feedback. Don't stop :)
In this case I think the memory lead comes from the class variables of GLMHintableActionButtonBrick. Clearing them up removes all instances of playground and spotter from my image. We need to find a better design for that. Cheers, Andrei On Tue, Mar 24, 2015 at 9:38 PM, Henrik Sperre Johansen < henrik.s.johan...@veloxit.no> wrote: > A tiny bit of code review while I'm at it... > > GTSpotterResultsBrick >> initialize > super initialize > self band hSpaceFill. > self announcer weak subscribe: GLMBrickScrollPositionChanged send: > #onScrolled to: self > > This is a tempting, but sneaky anti-pattern, you should never, ever, ever > have to subscribe to your own announcer: > The reason for calling it an anti-pattern is; if your code actually depends > on this, it means other sources might invoke changes in you indirectly > through your announcer, which quickly becomes debugging hell if you allow > it, and something screws up. (I speak from experience) > > It's much easier to understand when done directly, in this case that means > extending the super method where announcement is made: > > GTSpotterResultsBrick >> privateScrollPosition:anInteger > super privateScrollPosition:anInteger. > self onScrolled > > Cheers, > Henry > > P.S. Announcements are objects, they are intended to hold the data > subscribers might be interested in. > Whenever you find yourself writing something like: > someAnnouncer announce: SomeAnnouncement new > ask yourself twice if that may lead to subscribers accessing state that > would more naturally be part of the announcement through other channels > (such as keeping extra instvars, etc). > > > > -- > View this message in context: > http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >
