Re: [Pharo-project] Announcer methods are bloated

2011-04-20 Thread Stéphane Ducasse
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 tha

Re: [Pharo-project] Announcer methods are bloated

2011-04-20 Thread Stéphane Ducasse
+ 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 awk

Re: [Pharo-project] Announcer methods are bloated

2011-04-19 Thread Henrik Sperre Johansen
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 PragmaCollect

Re: [Pharo-project] Announcer methods are bloated

2011-04-19 Thread DougEdmunds
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 (subscr

Re: [Pharo-project] Announcer methods are bloated

2011-04-19 Thread Henrik Sperre Johansen
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

Re: [Pharo-project] Announcer methods are bloated

2011-04-19 Thread Stéphane Ducasse
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

Re: [Pharo-project] Announcer methods are bloated

2011-04-19 Thread DougEdmunds
Further bloat: This same aliasing bloat is proliferated into WeakSubscriptionBuilder, which also has 5 methods where it only needs 2. -- View this message in context: http://forum.world.st/Announcer-methods-are-bloated-tp3461131p3461157.html Sent from the Pharo Smalltalk mailing list archive a

[Pharo-project] Announcer methods are bloated

2011-04-19 Thread DougEdmunds
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