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) |
Further bloat:
This same aliasing bloat is proliferated into WeakSubscriptionBuilder, which also has 5 methods where it only needs 2. |
In reply to this post by DougEdmunds
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) > > > > > -- > View this message in context: http://forum.world.st/Announcer-methods-are-bloated-tp3461131p3461131.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
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) 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 |
In reply to this post by Stéphane Ducasse
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 |
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 > 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 |
+ 1
> 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 > |
In reply to this post by DougEdmunds
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. > |
Free forum by Nabble | Edit this page |