when:send:to: vs. subscribe:send:to:

Hi

in announcer we have

when: anAnnouncementClass send: aSelector to: anObject
     "Declare that when anAnnouncementClass is raised, anObject should
receive the message aSelector.
     When the message expects one argument (eg #fooAnnouncement:) the
announcement is passed as argument.
     When the message expects two arguments (eg
#fooAnnouncement:announcer:) both the announcement and the announcer
     are passed as argument"

     ^ self subscribe: anAnnouncementClass send: aSelector to: anObject


could we reduce the cognitive load and make sure that the API is only
one protocol for example when: send: to:?
I found it confusing and I have to check that this is indeed the same.
I think that having one way is far enough.

What do you think?
Stef

+1.

We already deprecated on:send:to:/on:do: and I think we should do the same for the subscribe:send:to:.

Thanks Doru. I thought the same. Because each time I read subscribe: my mind stops for about half or a second until I remember that this is
the same as when: send: to:

Doru

On Sat, Sep 5, 2015 at 10:24 PM, stepharo <[hidden email]> wrote:

Hi

in announcer we have

when: anAnnouncementClass send: aSelector to: anObject
    "Declare that when anAnnouncementClass is raised, anObject should receive the message aSelector.
    When the message expects one argument (eg #fooAnnouncement:) the announcement is passed as argument.
    When the message expects two arguments (eg #fooAnnouncement:announcer:) both the announcement and the announcer
    are passed as argument"

    ^ self subscribe: anAnnouncementClass send: aSelector to: anObject


could we reduce the cognitive load and make sure that the API is only one protocol for example when: send: to:?
I found it confusing and I have to check that this is indeed the same.
I think that having one way is far enough.

What do you think?
Stef

--

www.tudorgirba.com

"Every thing has its own flow"

On 06-09-15 10:37, stepharo wrote:
When looking at the implementation, it looks as if we should
replace all #when:send:to: by #subscribe:when:do:, not the other way
around.

Where is this all coming from?

Stephan

An attempt at compatibility.
IIRC; the original VW Announcements use when:send:to: (polymorphic with the old event system), while Lukas' implementation from Seaside use(d/s) subscribe:when:do:

My 2c; If you need to pick one over the other, choose when:send:to.

Cheers,
Henry

Le 08/09/2015 10:13, Stephan Eggermont a écrit :
I think that #when:send:to: is more explicit and more understandable,
but this is a personal opinion.

--
Cheers
Cyril

Me too :)
I do not care that they is a registration mechanism behind.

Stef

Le 8/9/15 16:30, Ferlicot D. Cyril a écrit :

> Am 08.09.2015 um 22:49 schrieb stepharo <[hidden email]>:
>
> Me too :)
> I do not care that they is a registration mechanism behind.
>
But you get a subscription back. Und the user should be aware of that there is no magical unsubscribe mechanism. So this no reason for me but I still like when:send:to: better although it feels a bit awkward.

Norbert

Note that when:send:to: already existed in VW before announcements (it did work with a symbol like when: #someAspectChanged send: #someAction to: self, and this was tiggered thru dependents mechanism - self changed: #someAspectChanged...).

yes

IMO, it is very expressive, whatever the underlying mechanism (dependents or Announcement).

+ 1

2015-09-09 8:49 GMT+02:00 Norbert Hartl <[hidden email]>:

> Am 08.09.2015 um 22:49 schrieb stepharo <[hidden email]>:
>
> Me too :)
> I do not care that they is a registration mechanism behind.
>
But you get a subscription back. Und the user should be aware of that there is no magical unsubscribe mechanism. So this no reason for me but I still like when:send:to: better although it feels a bit awkward.

Norbert

> Stef
>
> Le 8/9/15 16:30, Ferlicot D. Cyril a écrit :
>> Le 08/09/2015 10:13, Stephan Eggermont a écrit :
>>
>>> When looking at the implementation, it looks as if we should
>>> replace all #when:send:to: by #subscribe:when:do:, not the other way
>>> around.
>>>
>>> Where is this all coming from?
>>>
>>> Stephan
>> I think that #when:send:to: is more explicit and more understandable,
>> but this is a personal opinion.
>
>