Stéphane Ducasse | 1 Nov 2009 09:38
Picon
Picon
Favicon
Gravatar

Re: About AXAnnouncements (was: some Announcements related questions)

Yes for weak, I agree for set may be some people use that.
Now I would like to hear levente usage of announcement.
And igor having a simple but COMMON infrastructure is important
so we need the core.

Now I would also like to know the cost of always broadcasting. I do not
remember correctly but in vassili'blog there were some points to avoid  
that.
Because in the past, in Smalltalk the dependency where broadcasting to  
all the
dependents and this was inadequate and after they introduce  
on:when:.....
to get only the right listener updated.

Stef

On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:

>> In current core image, Announcements is quite small (just around 10
>> methods totally) and i doubt it provides enough
>> flexibility which would not require adding & reinventing additional
>> useful stuff on top of it.
>
> I have used these announcements in many large projects and I never
> needed to add anything. In fact, I would even vote to remove
> AnnouncementSet as I never used it or saw it used anywhere. Initially,
> I found it cool because the same trick is applied in the Exception
> hierarchy. Major projects like OmniBrowser (and to some extent also
> Seaside) use an even smaller subset of the functionality provided in
> the core package.
(Continue reading)

Alexandre Bergel | 2 Nov 2009 13:06
Picon

Re: About AXAnnouncements (was: some Announcements related questions)

> Now I would also like to know the cost of always broadcasting. I do  
> not
> remember correctly but in vassili'blog there were some points to avoid
> that.
> Because in the past, in Smalltalk the dependency where broadcasting to
> all the
> dependents and this was inadequate and after they introduce
> on:when:.....
> to get only the right listener updated.

Yes, broadcasting was the reason why OBPackageBrowser was slow before  
we refactored it.
Mondrian and OBPackageBrowser are happy with the current Announcement  
infrastructure.

Cheers,
Alexandre

>
> On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
>
>>> In current core image, Announcements is quite small (just around 10
>>> methods totally) and i doubt it provides enough
>>> flexibility which would not require adding & reinventing additional
>>> useful stuff on top of it.
>>
>> I have used these announcements in many large projects and I never
>> needed to add anything. In fact, I would even vote to remove
>> AnnouncementSet as I never used it or saw it used anywhere.  
>> Initially,
(Continue reading)

Alexandre Bergel | 2 Nov 2009 13:16
Picon

Re: About AXAnnouncements (was: some Announcements related questions)

>> Now I would also like to know the cost of always broadcasting. I do  
>> not
>> remember correctly but in vassili'blog there were some points to  
>> avoid
>> that.
>
> Yes, broadcasting was the reason why OBPackageBrowser was slow  
> before we refactored it.

Actually, the sloppiness came from the handlers associated to events.  
They generated way too many refreshes. Broadcasting events did not  
appear to be that slow.

Users of an event mechanism have the tendencies to broadcast events  
more than it should be.

Alexandre

>
>
>>
>> On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
>>
>>>> In current core image, Announcements is quite small (just around 10
>>>> methods totally) and i doubt it provides enough
>>>> flexibility which would not require adding & reinventing additional
>>>> useful stuff on top of it.
>>>
>>> I have used these announcements in many large projects and I never
>>> needed to add anything. In fact, I would even vote to remove
(Continue reading)

Alexandre Bergel | 2 Nov 2009 13:16
Picon

Re: About AXAnnouncements (was: some Announcements related questions)

>> Now I would also like to know the cost of always broadcasting. I do  
>> not
>> remember correctly but in vassili'blog there were some points to  
>> avoid
>> that.
>
> Yes, broadcasting was the reason why OBPackageBrowser was slow  
> before we refactored it.

Actually, the sloppiness came from the handlers associated to events.  
They generated way too many refreshes. Broadcasting events did not  
appear to be that slow.

Users of an event mechanism have the tendencies to broadcast events  
more than it should be.

Alexandre

>
>
>>
>> On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
>>
>>>> In current core image, Announcements is quite small (just around 10
>>>> methods totally) and i doubt it provides enough
>>>> flexibility which would not require adding & reinventing additional
>>>> useful stuff on top of it.
>>>
>>> I have used these announcements in many large projects and I never
>>> needed to add anything. In fact, I would even vote to remove
(Continue reading)

Alexandre Bergel | 2 Nov 2009 13:06
Picon

Re: About AXAnnouncements (was: some Announcements related questions)

> Now I would also like to know the cost of always broadcasting. I do  
> not
> remember correctly but in vassili'blog there were some points to avoid
> that.
> Because in the past, in Smalltalk the dependency where broadcasting to
> all the
> dependents and this was inadequate and after they introduce
> on:when:.....
> to get only the right listener updated.

Yes, broadcasting was the reason why OBPackageBrowser was slow before  
we refactored it.
Mondrian and OBPackageBrowser are happy with the current Announcement  
infrastructure.

Cheers,
Alexandre

>
> On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
>
>>> In current core image, Announcements is quite small (just around 10
>>> methods totally) and i doubt it provides enough
>>> flexibility which would not require adding & reinventing additional
>>> useful stuff on top of it.
>>
>> I have used these announcements in many large projects and I never
>> needed to add anything. In fact, I would even vote to remove
>> AnnouncementSet as I never used it or saw it used anywhere.  
>> Initially,
(Continue reading)


Gmane