[Pharo-project] Why don't we always register weakly in SystemAnnouncer?

Igor Stasenko 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:
> Igor
>
> could you tell us what we should do with the issues on handle (feedback of lukas)
>
> http://code.google.com/p/pharo/issues/detail?id=5145
>
> Stef

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
>>> weakly:
>>>
>>> TestRunner >> initialize
>>> .....
>>> SystemAnnouncer current
>>>         weak
>>>         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
>>> class?
>>> 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,
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>



-- 
Best regards,
Igor Stasenko.




More information about the Pharo-dev mailing list