On 16 June 2012 23:12, Guillermo Polito <[email protected]> wrote:
> So, what about making weak a default and notWeak the explicit one? :D
>
you can, but this could lead to confusion.
because 'announcer weak subscribe: ' is explicit
while 'announcer subscribe: ' is implicit..
so i would leave it like it is now.

>
> On Sat, Jun 16, 2012 at 11:09 PM, Igor Stasenko <[email protected]> wrote:
>>
>> On 16 June 2012 22:51, Mariano Martinez Peck <[email protected]>
>> 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.

Reply via email to