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:. Doru On Sat, Sep 5, 2015 at 10:24 PM, stepharo <stepharo@free.fr> 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"
Le 5/9/15 22:42, Tudor Girba a écrit :
+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 <stepharo@free.fr <mailto:stepharo@free.fr>> 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 <http://www.tudorgirba.com>
"Every thing has its own flow"
On 06-09-15 10:37, stepharo wrote:
Le 5/9/15 22:42, Tudor Girba a écrit :
+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:
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
On 08 Sep 2015, at 10:13 , Stephan Eggermont <stephan@stack.nl> wrote:
On 06-09-15 10:37, stepharo wrote:
Le 5/9/15 22:42, Tudor Girba a écrit :
+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:
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 :
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. -- 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 :
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.
Am 08.09.2015 um 22:49 schrieb stepharo <stepharo@free.fr>:
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.
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...). IMO, it is very expressive, whatever the underlying mechanism (dependents or Announcement). 2015-09-09 8:49 GMT+02:00 Norbert Hartl <norbert@hartl.name>:
Am 08.09.2015 um 22:49 schrieb stepharo <stepharo@free.fr>:
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.
2015-09-09 6:21 GMT-03:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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...).
IMO, it is very expressive, whatever the underlying mechanism (dependents or Announcement).
+1
Dolphin Smalltalk also uses #when:send:to:, and also #when:sendTo: and #when:perform: Regards! Esteban A. Maringolo
Le 9/9/15 11:21, Nicolas Cellier a écrit :
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 <norbert@hartl.name <mailto:norbert@hartl.name>>:
> Am 08.09.2015 um 22:49 schrieb stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>: > > 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. > >
Excuse me, but what about the following messages MessageBrowser browse: ({WeakSubscriptionBuilder>>#on:do:. WeakSubscriptionBuilder>>#on:send:to:}) should be deprecated, or not? On Sat, Sep 5, 2015 at 5:24 PM, stepharo <stepharo@free.fr> 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
-- Bernardo E.C. Sent from a cheap desktop computer in South America.
Probably yes. However, in that case the issue is at least internal to the implementation as nobody will actually use that class directly. Cheers, Doru On Sat, Sep 5, 2015 at 11:56 PM, Bernardo Ezequiel Contreras < vonbecmann@gmail.com> wrote:
Excuse me, but what about the following messages
MessageBrowser browse: ({WeakSubscriptionBuilder>>#on:do:. WeakSubscriptionBuilder>>#on:send:to:})
should be deprecated, or not?
On Sat, Sep 5, 2015 at 5:24 PM, stepharo <stepharo@free.fr> 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
-- Bernardo E.C.
Sent from a cheap desktop computer in South America.
-- www.tudorgirba.com "Every thing has its own flow"
participants (9)
-
Bernardo Ezequiel Contreras -
Esteban A. Maringolo -
Ferlicot D. Cyril -
Henrik Johansen -
Nicolas Cellier -
Norbert Hartl -
Stephan Eggermont -
stepharo -
Tudor Girba