[Pharo-project] Why don't we always register weakly in SystemAnnouncer?
siguctua at gmail.com
Sun Jun 17 05:24:32 EDT 2012
On 17 June 2012 09:38, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
> could you tell us what we should do with the issues on handle (feedback of lukas)
oh, i thought this was already integrated.
i think we shall integrate it, and then we will see.
the main change is allow object-based announcements, as long an object
understands #handlesAnnouncement: message.
> On Jun 16, 2012, at 11:09 PM, Igor Stasenko wrote:
>> On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>>> Hi, with the help of Guille I noticed that normal instances usually register
>>> TestRunner >> initialize
>>> SystemAnnouncer current
>>> on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved,
>>> ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self.
>>> and classes don't:
>>> TestCase class >> registerForNotifications
>>> SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved
>>> send: #methodChanged: to: self.
>>> so..Guille told me this is because usually the cycle-life of instances is
>>> short in comparisson with classes. But classes can be removed as well. What
>>> happen then? the announcer will hold always a reference to an obsolete
>>> my question is, should we always use weakly? if not, why ?
>> Yes, i think most of subscriptions should be weak, because it is kind
>> of implied by loose-coupling.
>> And classes is not an exception - because then you don't need to
>> explicitly unsubscribe,
>> and don't have to worry that it kept in memory just because you forgot to do it.
>>> thanks for the explanation,
>> Best regards,
>> Igor Stasenko.
More information about the Pharo-dev