Hello Everyone,
The following repo contains before and after examples of replacing the Dependency Mechanism with the Observer Pattern: https://github.com/dhnorton/Cuis-Smalltalk-light Please take a look at this and tell me what needs to change. I'm trying to supply an example of the Observer Pattern so that others might use #when:send:to: with less difficulty than I experienced. There may be better examples but I picked one from the Blue Book. It seems that #when:send:to: is necessary but not sufficient as a replacement for the Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or #update and I am still not comfortable with how to choose the parameters. This may be an example of the difficulty in explaining the obvious, I'm not sure :-) The #changed method was replaced with #triggerEvent: with a symbol argument which is referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT. The #update: method was retained, as a convenience; it also needs to agree with one of the arguments of #when:send:to: and could have been different. Please tell me if any of this is wrong. Thanks. - Dan _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Fri, 13 Nov 2015 12:58:22 -0500
"Dan Norton" <[hidden email]> wrote: > Hello Everyone, > > The following repo contains before and after examples of replacing the Dependency > Mechanism with the Observer Pattern: > > https://github.com/dhnorton/Cuis-Smalltalk-light > > Please take a look at this and tell me what needs to change. Dan, Good start. I would suggest a deeper example. Lights could be a model with a presenter (LightPanel) which shows the lights. E.g. open a layout morph with a row of elipses (circles) which are red/green (or whatever) for off/on. Clicking on a light changes the model (Lights subclass ActiveModel), which signals triggerEvent: #colorChange with: aColor. You can look in Morphic-Misc1 at RadioButtonMorph to see how to handle clicks. Workspace code could also turn off/on or just toggle lights in the model, with the LightPanel presenter updating appropriately. One can then add a bit of wackyness, like using different colors than red/green and the presenter will show the proper color.. $0.02. -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
On 13 Nov 2015 at 18:33, KenD wrote:
> On Fri, 13 Nov 2015 12:58:22 -0500 > "Dan Norton" <[hidden email]> wrote: > > > Hello Everyone, > > > > The following repo contains before and after examples of replacing > the Dependency > > Mechanism with the Observer Pattern: > > > > https://github.com/dhnorton/Cuis-Smalltalk-light > > > > Please take a look at this and tell me what needs to change. > > Dan, > > Good start. > > I would suggest a deeper example. > Hmm, I made it stark simple in order to focus on the basics. However, a couple of possibilities could be: a 3-bulb traffic light with a change button (incremental add-on), or a drag race tree (elaborate). - Dan > Lights could be a model with a presenter (LightPanel) which shows > the lights. E.g. open a layout morph with a row of elipses > (circles) which are red/green (or whatever) for off/on. > > Clicking on a light changes the model (Lights subclass ActiveModel), > which signals > triggerEvent: #colorChange with: aColor. > > You can look in Morphic-Misc1 at RadioButtonMorph to see how to > handle clicks. > > Workspace code could also turn off/on or just toggle lights in the > model, with the LightPanel presenter updating appropriately. > > One can then add a bit of wackyness, like using different colors > than red/green and the presenter will show the proper color.. > > $0.02. > -KenD > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Sun, 15 Nov 2015 13:47:00 -0500
"Dan Norton" <[hidden email]> wrote: > Hmm, I made it stark simple in order to focus on the basics. If a "light" does not have a visual representation, I would call it a "switch". $0.02 -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
On 15 Nov 2015 at 12:35, KenD wrote:
> On Sun, 15 Nov 2015 13:47:00 -0500 > "Dan Norton" <[hidden email]> wrote: > > > > Hmm, I made it stark simple in order to focus on the basics. > > If a "light" does not have a visual representation, I would call it > a "switch". > Good point. I see the light of that; however, stark though it be, at least it lets you see state in the Transcript. The Blue Book used Light and TrafficLight then left you to use inspectors I presume. They didn't say :) - Dan _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
In reply to this post by Dan Norton
Hi Dan,
On 13/11/2015 02:58 p.m., Dan Norton wrote: > Hello Everyone, > > The following repo contains before and after examples of replacing the Dependency > Mechanism with the Observer Pattern: > > https://github.com/dhnorton/Cuis-Smalltalk-light > > Please take a look at this and tell me what needs to change. I'm trying to supply an example > of the Observer Pattern so that others might use #when:send:to: with less difficulty than I > experienced. There may be better examples but I picked one from the Blue Book. > > It seems that #when:send:to: is necessary but not sufficient as a replacement for the > Dependency Mechanism. In this example, it replaced #addDependent:, not #changed or > #update and I am still not comfortable with how to choose the parameters. This may be an > example of the difficulty in explaining the obvious, I'm not sure :-) > > The #changed method was replaced with #triggerEvent: with a symbol argument which is > referred to in one of the arguments of #when:send:to: and that's the only constraint AFAICT. > > The #update: method was retained, as a convenience; it also needs to agree with one of the > arguments of #when:send:to: and could have been different. > > Please tell me if any of this is wrong. Thanks. > > - Dan I think the idea of #when:send:to: is to use event names and actions that make sense to your model (and not #changed and #update:). For instance, in Example2>>#lights:, I would change the line: eachLight when: #changed send: #update: to: dependentLight with: self to read: eachLight when: #turnedOn send: #turnOff to: dependentLight And, in #turnOn, make it do: self triggerEvent: #turnedOn Doesn't this read better? Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On 16 Nov 2015 at 21:11, Juan Vuletich wrote:
> Hi Dan, > > On 13/11/2015 02:58 p.m., Dan Norton wrote: > > Hello Everyone, > > > > The following repo contains before and after examples of replacing > the Dependency > > Mechanism with the Observer Pattern: > > > > https://github.com/dhnorton/Cuis-Smalltalk-light > > > > Please take a look at this and tell me what needs to change. I'm > trying to supply an example > > of the Observer Pattern so that others might use #when:send:to: > with less difficulty than I > > experienced. There may be better examples but I picked one from > the Blue Book. > > > > It seems that #when:send:to: is necessary but not sufficient as a > replacement for the > > Dependency Mechanism. In this example, it replaced #addDependent:, > not #changed or > > #update and I am still not comfortable with how to choose the > parameters. This may be an > > example of the difficulty in explaining the obvious, I'm not sure > :-) > > > > The #changed method was replaced with #triggerEvent: with a symbol > argument which is > > referred to in one of the arguments of #when:send:to: and that's > the only constraint AFAICT. > > > > The #update: method was retained, as a convenience; it also needs > to agree with one of the > > arguments of #when:send:to: and could have been different. > > > > Please tell me if any of this is wrong. Thanks. > > > > - Dan > > I think the idea of #when:send:to: is to use event names and actions > that make sense to your model (and not #changed and #update:). For > instance, in Example2>>#lights:, I would change the line: > > eachLight when: #changed send: #update: to: dependentLight > with: self > > to read: > > eachLight when: #turnedOn send: #turnOff to: > dependentLight > > And, in #turnOn, make it do: > > self triggerEvent: #turnedOn > > > Doesn't this read better? > +2 ...because yes, it reads better, but there's more: #when:send:to: replaces #when:send:to:with: in Light2, #update: goes away, with a little factoring The #triggerEvent: arg is changed to #turnedOn. This is elegant. - Dan _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On 16/11/2015 10:50 p.m., Dan Norton wrote:
> On 16 Nov 2015 at 21:11, Juan Vuletich wrote: > >> Hi Dan, >> >> On 13/11/2015 02:58 p.m., Dan Norton wrote: >>> Hello Everyone, >>> >>> The following repo contains before and after examples of replacing >> the Dependency >>> Mechanism with the Observer Pattern: >>> >>> https://github.com/dhnorton/Cuis-Smalltalk-light >>> >>> Please take a look at this and tell me what needs to change. I'm >> trying to supply an example >>> of the Observer Pattern so that others might use #when:send:to: >> with less difficulty than I >>> experienced. There may be better examples but I picked one from >> the Blue Book. >>> It seems that #when:send:to: is necessary but not sufficient as a >> replacement for the >>> Dependency Mechanism. In this example, it replaced #addDependent:, >> not #changed or >>> #update and I am still not comfortable with how to choose the >> parameters. This may be an >>> example of the difficulty in explaining the obvious, I'm not sure >> :-) >>> The #changed method was replaced with #triggerEvent: with a symbol >> argument which is >>> referred to in one of the arguments of #when:send:to: and that's >> the only constraint AFAICT. >>> The #update: method was retained, as a convenience; it also needs >> to agree with one of the >>> arguments of #when:send:to: and could have been different. >>> >>> Please tell me if any of this is wrong. Thanks. >>> >>> - Dan >> I think the idea of #when:send:to: is to use event names and actions >> that make sense to your model (and not #changed and #update:). For >> instance, in Example2>>#lights:, I would change the line: >> >> eachLight when: #changed send: #update: to: dependentLight >> with: self >> >> to read: >> >> eachLight when: #turnedOn send: #turnOff to: >> dependentLight >> >> And, in #turnOn, make it do: >> >> self triggerEvent: #turnedOn >> >> >> Doesn't this read better? >> > +2 > ...because yes, it reads better, but there's more: > > #when:send:to: replaces #when:send:to:with: > > in Light2, #update: goes away, with a little factoring > > The #triggerEvent: arg is changed to #turnedOn. This is elegant. > > - Dan > Yes! And this way, 'senders' and 'implementors' take you right to the spot. Cheers, Juan Vuletich > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Free forum by Nabble | Edit this page |