On 19.04.2011 21:40, Stéphane Ducasse wrote:

Hi Doug

in addition I do not like to use on:do: since I prefer to keep it for exception. Now did you check senders of each of these methods? What would be a path to go to your solution. In fact subscribe:do: is not a really good name too. I prefer on: do: (even if I do not like the overload) and on:send:do:

I think that we could deprecate when:do: first. Then may be deprecate subscribe:do:

Stef

On Apr 19, 2011, at 8:07 PM, DougEdmunds wrote:

...

If Announcements are newly added to core (discussion at http://forum.world.st/Announcements-in-core-images-tc3188286.html), why not start with a trimmed down set of methods? Why start with bloat?

Announcer has these two core methods:

1) subscribe:do 2) subscribe:send:to:

are fine.

There is no need for 3) on:do (just calls 1) 4) on:send:to: (just calls 2) 5) when:do (also justs calls 1) Personally, I'd keep when:do:, add when:do:for: and when:send:to, and deprecate the rest. Why? Mainly because that makes it the same as what you find in VisualWorks, so if Announcements happen to become an item for standardization some time in the future, there's less to quarrel about :) It also fits in nicely with being a replacement for events.

Cheers, Henry

On 20.04.2011 00:00, DougEdmunds wrote:

I'd vote to keep the subscribe:do: and subscribe:send:to methods, since that seems to most clearly identify what they are doing. Maybe better would be subscribeTo:do: and subscribeTo:send:to:

A good example is the instance var 'announcer' in PragmaCollector which holds requests to receive (subscriptions to) 'PragmaAnnouncement' and to 'PragmaCollectorReset' announcements.

subscribe: anAnnouncement send: aSelector to: anObject "see Announcements packages" self announcer subscribe: anAnnouncement send: aSelector to: anObject

whenChangedSend: aSelector to: anObject "record a change listener" self subscribe: PragmaAnnouncement send: aSelector to: anObject

whenResetSend: aSelector to: anObject "record a change listener" self subscribe: PragmaCollectorReset send: aSelector to: anObject

In my eyes, an issue with subscribeTo: is that it kind of encourage giving announcement classes noun names rather than using verbs, if you want subscriptions to read naturally. on: does not have that problem to the same extent, and when: certainly doesn't. subscribe: reads awkwardly no matter what you name them, imo :) Of course, subscribe:'s big advantage is that it's not polymorphic with any existing system. Cheers, Henry

On Apr 20, 2011, at 12:00 AM, DougEdmunds wrote:

I'd vote to keep the subscribe:do: and subscribe:send:to methods, since that seems to most clearly identify what they are doing.

I do not think so. For me subscribe:do: looks like initialization.... Subscribing to something does not mean that you should do something in reaction.

Maybe better would be subscribeTo:do: and subscribeTo:send:to:

A good example is the instance var 'announcer' in PragmaCollector which holds requests to receive (subscriptions to) 'PragmaAnnouncement' and to 'PragmaCollectorReset' announcements.

subscribe: anAnnouncement send: aSelector to: anObject "see Announcements packages" self announcer subscribe: anAnnouncement send: aSelector to: anObject

whenChangedSend: aSelector to: anObject "record a change listener" self subscribe: PragmaAnnouncement send: aSelector to: anObject

whenResetSend: aSelector to: anObject "record a change listener" self subscribe: PragmaCollectorReset send: aSelector to: anObject

-- View this message in context: http://forum.world.st/Announcer-methods-are-bloated-tp3461131p3461644.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.