Announcer methods are bloated

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Announcer methods are bloated

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 need for
3) on:do (just calls 1)
4) on:send:to: (just calls 2)
5) when:do (also justs calls 1)


Reply | Threaded
Open this post in threaded view
|

Re: Announcer methods are bloated

DougEdmunds
Further bloat:
This same aliasing bloat is proliferated into WeakSubscriptionBuilder,
which also has 5 methods where it only needs 2.
Reply | Threaded
Open this post in threaded view
|

Re: Announcer methods are bloated

Stéphane Ducasse
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Announcer methods are bloated

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: 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

Reply | Threaded
Open this post in threaded view
|

Re: Announcer methods are bloated

DougEdmunds
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


Reply | Threaded
Open this post in threaded view
|

Re: Announcer methods are bloated

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 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

Reply | Threaded
Open this post in threaded view
|

Re: Announcer methods are bloated

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 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Announcer methods are bloated

Stéphane Ducasse
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.
>