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.johansen@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.