- Pharo-users - lists.pharo.org

Re: creating a subclass in system browser

by Richard O'Keefe

I hadn't actually noticed the "+" sign but it was there in V7 and is there in V9 on Windows. On Wed, 28 Apr 2021 at 03:15, Sanjay Minni <sm(a)planage.com> wrote: > Don't think it's there in v9. Check in v8 > > On Tue, 27 Apr, 2021, 7:50 pm Russ Whaley, <whaley.russ(a)gmail.com> wrote: > >> Can you send a screenshot of the plus button? I'm using v9 on MacOS and >> I don't see a class + button... >> >> On Tue, Apr 27, 2021 at 9:47 AM kmo <voxkmp(a)gmail.com> wrote: >> >>> Doing it by hand is fiddly and error-prone. I know - because that's the >>> way I >>> used to do it before I realised that the plus button at the top of the >>> browser bottom panel did it for me. (I had no idea that there was also a >>> menu option on the refactorings menu). I think you might find the button >>> to >>> be the better way - I did. >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com >> >

April 29, 2021

Re: Mooc on Advanced OO design looking for interested teachers.

by StÃ©phane Ducasse

Thanks! > On 27 Apr 2021, at 02:38, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > StÃ©phane, > > We, at our local hackerspace maybe interested in using your contents for our workshops. But, its a pretty informal curriculum and is project/problem oriented, so we may not cover all topics or even approach them in order. > > Thanks for all your work. > > Offray > > On 23/04/21 5:41 a. m., StÃ©phane Ducasse wrote: >> Hello >> >> Iâm starting to write a Mooc on Advanced OO design. >> It will be in the same format that the Pharo Mooc. >> I would like to know if some of you can be interested using part of this mooc in their curriculum. >> It will help me for a funding agency Iâm applying to. >> >> S. >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> >> 03 59 35 87 52 >> Assistant: Aurore Dalle >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

April 28, 2021

Re: creating a subclass in system browser

by StÃ©phane Ducasse

Please open issue so that your remarks do not get lost. > On 27 Apr 2021, at 17:15, Christopher Fuhrman <christopher.fuhrman(a)etsmtl.ca> wrote: > > One thing I find challenging when teaching Pharo to new students -- especially those accustomed to IDEs with files, which is pretty much all of them ;) -- is that there are sometimes menus (depending on the Pharo version) to add a new package, new class, new protocol, but not a new method, etc. > > For onboarding new users, I think it's important that these things be intuitive and consistent, especially since updating tutorials takes time. They are super important because inconsistencies become barriers to onboarding new people. My point here is not that a menu option necessarily exists, but that we have a consistent way to explain how to create things even when Pharo changes. Apple used to have 10 commandments for keyboard shortcuts, and I think a similar idea could apply to having consistency in these elements of Pharo. > > Here are some related perspectives: > https://stackoverflow.com/questions/48034993/creation-of-a-class-in-pharo-s… <https://stackoverflow.com/questions/48034993/creation-of-a-class-in-pharo-s…> > https://stackoverflow.com/questions/53374761/how-to-add-a-new-method-in-pha… <https://stackoverflow.com/questions/53374761/how-to-add-a-new-method-in-pha…> > > > On Tue, 27 Apr 2021 at 09:47, kmo <voxkmp(a)gmail.com <mailto:voxkmp@gmail.com>> wrote: > Doing it by hand is fiddly and error-prone. I know - because that's the way I > used to do it before I realised that the plus button at the top of the > browser bottom panel did it for me. (I had no idea that there was also a > menu option on the refactorings menu). I think you might find the button to > be the better way - I did. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> > > > -- > Christopher Fuhrman, P.Eng., PhD > Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'information > ÃTS (Ãcole de technologie supÃ©rieure) > > http://profs.etsmtl.ca/cfuhrman <http://profs.etsmtl.ca/cfuhrman> > +1 514 396 8638 > L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

April 28, 2021

Re: creating a subclass in system browser

by Esteban Maringolo

It's been there as a refactoring for a while. Why a refactoring? Who knows... Esteban A. Maringolo On Tue, Apr 27, 2021 at 1:59 PM kmo <voxkmp(a)gmail.com> wrote: > / a red circled exclamation point (hovering says 'Refactorings' - which > has a > menu for the +New subclass./ > > That sounds completely horrible. Surely that's never going to remain in the > official release. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 27, 2021

Re: Announcements - and whether its bad to check if a subscription would be handled?

by Richard Sargent

Upcasting is a behavioural feature. You would not play with the announcements. The class would receive it and its handler would delegate to a parent if necessary. On Tue, Apr 27, 2021 at 10:14 AM Tim Mackinnon <tim(a)testit.works> wrote: > I appreciate the further thoughts of others - I should go back and look > at Dolphin code (I think there are ways to run it on Mac now?). > > The upcasting Richard refers to is what I'm trying to do - which is how I > got interested in understanding if you could tell if someone was subscribed > to an event, as if not - then you could pass it up to the parent to - > re-announce it via the announcer of that parent (in CP - the announcers are > by presenter, so hence the handoff). > > In theory it's quite neat - but I did see some deprecations in Announcer > trying to stop too much knowledge leaking out. However, knowing if an event > has any listeners doesn't on the surface seem too controversial - but I can > see that everyone approaches this idea with understandable caution. > Possibly this is masking some other approach to this - or - I can happily > have an extension method on Announcer - or - I can propose this method in a > PR for symetry with some of the other #hasXXXX methods. > > Tim > > On Tue, 27 Apr 2021, at 5:31 PM, Richard Sargent wrote: > > I have seen something called upcasting and downcasting (as contrasted with > broadcasting). Mostly, I have seen it in UI layers. > > e.g. a leaf node receives a change notification, decides it isn't > interested in handling the notification, and so passes it up to its parent, > etc. > > Downcasting is similar but in the opposite direction. e.g. a window > receives an event and asks its children to handle it, and they do the same. > In this case especially, the one that handles the event needs to mark it as > handled so that no one else is asked to handle it. > > On April 27, 2021 5:49:56 AM HST, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi guys - yes that fire and forget was always how I had viewed announcements, and potentially my scenario is misusing "announcements" which is why I was interested in views here. > > However - as announcements are typically a mechanism for farming out processing to others - how does one handle the scenario that you might only want one object to handle the announcement (and not others)? > > in my specific example, with MVP - a view, totally decoupled in a web browser, wants to pass on a button click to a presenter - however it not clear what the best mechanism to bubble up that handling should be? If the immediate presenter of the view can handle it - great - but if not, how would you continue to broadcast wider to see if someone higher up the parent component chain can handle it? > > If you go fire and forget (which is how I had viewed announcements prior to this specific case) - then you have the problem a different way - when someone processes an announcement it might already have been handled earlier and so the consumer either has to check first, or their work is simply ignored as the announcement payload could just filter a response out. > > In my head, I'm sort of thinking this is akin to CPU interrupt chaining - where an interrupt can cascade up a stack if not handled OR like object inheritance where an object can choose to override a message and stop it from cascading up the inheritance chain. > > Maybe announcements aren't intended for this at all - although it seems an elegant way to handle it - with just 1 method addition to Announcer (but it does slightly expose things - albeit in a structured way - and similar to the similar #hasSubscriber:). > > I'm sure it "depends" - but interested in other observations from the field, as I'm sure I'm not the first person to hit something like this. > > Tim > > On Tue, 27 Apr 2021, at 3:51 PM, Sven Van Caekenberghe wrote: > > The whole idea is to decouple producers and consumers, like in > messaging systems. > > You should not care if there are other listening, just like the > listeners should not care if there is someone posting data. > > Asking for subscribers is introducing a coupling. > > The announcement mechanism will/should deal with this in an efficient way. > > On 27 Apr 2021, at 16:03, Tim Mackinnon <tim(a)testit.works> wrote: > > From my rather long ramble below - I am still curious if its distasteful to have a method on Announcer > > hasSubscriptionsHandling: anAnnouncement > "Answer true if I have any subscribers to anAnnouncement" > > ^(registry subscriptionsHandling: anAnnouncement ) notEmpty > > Tim > > On Thu, 22 Apr 2021, at 11:34 PM, Tim Mackinnon wrote: > > Hi everyone - Iâve always thought the article on announcements many > years ago was very cool - and we donât seem to use them as much as we > could (but equally they arenât a panacea to be overused everywhere > either - and they do get used in Pharo to some extent). > > Anyway, Iâve been playing around with CodeParadise (CP is a very cool > project, and Erik is very supportive and thinking about how to write > web apps a different wayâ¦ Iâm fascinated), > > And - CP uses announcements as mechanism to send events from the View > Client (in a web browser) to a Presenter on the server (which makes > total sense). > > In taking things for a spin, I hit an interesting problem on how in a > web component world, you should display a spelling test of words - > > e.g. SpellingTest â has many â> SpellingWord(s). > > > Initially I bunged it all in a single presenter with its associated > view, and it was a bit messy, and Erik guided me down a route (that CP > nicely supports) - that my SpellingTest view should have the name/date > of the test as well as an add word input field, but the list of current > Words (which I had bunged into a table) - were actually more elegant as > sub-components - hence a WordView - which renders a single word in a > DIV, and for the edit screen I was creating, a Delete button next to > the word (so you could delete it). So a 1 to many relationship > essentials. > > This is where the announcements kick in (and lead to my ultimate question). > > When you click the Delete button, if I use a sub component - my view > will generate a DeleteWordAnnouncement - which gets fed to my > SpellingWordPresenter - however words in this sense donât naturally > know their parent (the SpellingTest) - and its the parent test that has > a #deleteWord: method. > > Iâve been taking with Erik, on different ways to elegantly handle this. > > a) you could change the model so words know their parent (in my case, > Iâm using a 3rd party model for Flashcards, and they just donât know > this - and adapting them would be a nuisance > b) my TestPresenter could listen to announcements on the WordPresenter > - and I could get some communications between presenters (although > normally the Presenters just get events from Views, and pure domain > models - so it feels a bit abnormal to consider another Presenter as a > sort of model - but I could live with this > c) given the composable nature of views/presenters (and CP is base on a > WebComponent model) - you could bubble up Announcements, so that if an > event isnât handled by a viewâs immediate presenter, you could re-route > it to the parent of the View (the component owner) and see if itâs > presenter could do something. > > > I think (c) has a certain expectation to it - in fact when I converted > my initial one-presenter attempt into components, I still had listener > code in my TestPresenter that was expecting to get a deleteWord > announcement and I was initially surprised that I wasnât getting it (as > it was now just going to the Word component I had refactored out). > > So I wonder if others here would expect things to work this way too > (and are there other examples in the wild that lead you here - or scare > you away from this?). > > Back to my Announcement question - if C is a good idea - why doesnât > the Announcer class let you check if if will handle a particular > announcement? The API has #hasSubscriber: and #hasSubscriberClass: , > but its missing: > > hasSubscriptionsHandling: anAnnouncement > "Answer true if I have any subcribers to anAnnouncement" > > ^(registry subscriptionsHandling: anAnnouncement ) notEmpty > > > And I am wondering if this is because it's a bad thing to expect to be > able to check? In my case above, I would want to do this to know if CP > should instead try announcing a message to a parent presenter because > the current presenter wonât handle it. In my example above, my > WordComponentView will broadcast that the delete button was clicked, > but its actually a parent view which would reasonably want to listen to > this kind of event and process the delete. And in a many words > scenario (the Test has many words), its unrealistic for the parent to > register to listen to each word component individually (in fact CP sort > of hides this from you), however if you could listen to an event in > your TestView, it seems to come out quite nicely - and looks a bit > like this: > > viewCreated > super viewCreated. > > self view > when: CpNavigationAnnouncement > do: [ :action | self model goto: action location ]; > > when: CpAddWordAnnouncement do: [ :action | self addWord: action data > ]; > when: CpDeleteWordAnnouncement do: [ :action | self deleteWord: > action data ]. <â this is the one Iâm talking about > > > So Iâm curious on the overall thought process here, but in particular > whether I should even submit a PR on Announcer for > #hasSubscriptionsHandling: ? > > Tim > > >

April 27, 2021

Re: Announcements - and whether its bad to check if a subscription would be handled?

by Tim Mackinnon

I appreciate the further thoughts of others - I should go back and look at Dolphin code (I think there are ways to run it on Mac now?). The upcasting Richard refers to is what I'm trying to do - which is how I got interested in understanding if you could tell if someone was subscribed to an event, as if not - then you could pass it up to the parent to - re-announce it via the announcer of that parent (in CP - the announcers are by presenter, so hence the handoff). In theory it's quite neat - but I did see some deprecations in Announcer trying to stop too much knowledge leaking out. However, knowing if an event has any listeners doesn't on the surface seem too controversial - but I can see that everyone approaches this idea with understandable caution. Possibly this is masking some other approach to this - or - I can happily have an extension method on Announcer - or - I can propose this method in a PR for symetry with some of the other #hasXXXX methods. Tim On Tue, 27 Apr 2021, at 5:31 PM, Richard Sargent wrote: > I have seen something called upcasting and downcasting (as contrasted with broadcasting). Mostly, I have seen it in UI layers. > > e.g. a leaf node receives a change notification, decides it isn't interested in handling the notification, and so passes it up to its parent, etc. > > Downcasting is similar but in the opposite direction. e.g. a window receives an event and asks its children to handle it, and they do the same. In this case especially, the one that handles the event needs to mark it as handled so that no one else is asked to handle it. > > On April 27, 2021 5:49:56 AM HST, Tim Mackinnon <tim(a)testit.works> wrote: >> Hi guys - yes that fire and forget was always how I had viewed announcements, and potentially my scenario is misusing "announcements" which is why I was interested in views here. >> >> However - as announcements are typically a mechanism for farming out processing to others - how does one handle the scenario that you might only want one object to handle the announcement (and not others)? >> >> in my specific example, with MVP - a view, totally decoupled in a web browser, wants to pass on a button click to a presenter - however it not clear what the best mechanism to bubble up that handling should be? If the immediate presenter of the view can handle it - great - but if not, how would you continue to broadcast wider to see if someone higher up the parent component chain can handle it? >> >> If you go fire and forget (which is how I had viewed announcements prior to this specific case) - then you have the problem a different way - when someone processes an announcement it might already have been handled earlier and so the consumer either has to check first, or their work is simply ignored as the announcement payload could just filter a response out. >> >> In my head, I'm sort of thinking this is akin to CPU interrupt chaining - where an interrupt can cascade up a stack if not handled OR like object inheritance where an object can choose to override a message and stop it from cascading up the inheritance chain. >> >> Maybe announcements aren't intended for this at all - although it seems an elegant way to handle it - with just 1 method addition to Announcer (but it does slightly expose things - albeit in a structured way - and similar to the similar #hasSubscriber:). >> >> I'm sure it "depends" - but interested in other observations from the field, as I'm sure I'm not the first person to hit something like this. >> >> Tim >> >> On Tue, 27 Apr 2021, at 3:51 PM, Sven Van Caekenberghe wrote: >>> The whole idea is to decouple producers and consumers, like in >>> messaging systems. >>> >>> You should not care if there are other listening, just like the >>> listeners should not care if there is someone posting data. >>> >>> Asking for subscribers is introducing a coupling. >>> >>> The announcement mechanism will/should deal with this in an efficient way. >>> >>>> On 27 Apr 2021, at 16:03, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> From my rather long ramble below - I am still curious if its distasteful to have a method on Announcer >>>> >>>> hasSubscriptionsHandling: anAnnouncement >>>> "Answer true if I have any subscribers to anAnnouncement" >>>> >>>> ^(registry subscriptionsHandling: anAnnouncement ) notEmpty >>>> >>>> Tim >>>> >>>> On Thu, 22 Apr 2021, at 11:34 PM, Tim Mackinnon wrote: >>>>> Hi everyone - Iâve always thought the article on announcements many >>>>> years ago was very cool - and we donât seem to use them as much as we >>>>> could (but equally they arenât a panacea to be overused everywhere >>>>> either - and they do get used in Pharo to some extent). >>>>> >>>>> Anyway, Iâve been playing around with CodeParadise (CP is a very cool >>>>> project, and Erik is very supportive and thinking about how to write >>>>> web apps a different wayâ¦ Iâm fascinated), >>>>> >>>>> And - CP uses announcements as mechanism to send events from the View >>>>> Client (in a web browser) to a Presenter on the server (which makes >>>>> total sense). >>>>> >>>>> In taking things for a spin, I hit an interesting problem on how in a >>>>> web component world, you should display a spelling test of words - >>>>> >>>>> e.g. SpellingTest â has many â> SpellingWord(s). >>>>> >>>>> >>>>> Initially I bunged it all in a single presenter with its associated >>>>> view, and it was a bit messy, and Erik guided me down a route (that CP >>>>> nicely supports) - that my SpellingTest view should have the name/date >>>>> of the test as well as an add word input field, but the list of current >>>>> Words (which I had bunged into a table) - were actually more elegant as >>>>> sub-components - hence a WordView - which renders a single word in a >>>>> DIV, and for the edit screen I was creating, a Delete button next to >>>>> the word (so you could delete it). So a 1 to many relationship >>>>> essentials. >>>>> >>>>> This is where the announcements kick in (and lead to my ultimate question). >>>>> >>>>> When you click the Delete button, if I use a sub component - my view >>>>> will generate a DeleteWordAnnouncement - which gets fed to my >>>>> SpellingWordPresenter - however words in this sense donât naturally >>>>> know their parent (the SpellingTest) - and its the parent test that has >>>>> a #deleteWord: method. >>>>> >>>>> Iâve been taking with Erik, on different ways to elegantly handle this. >>>>> >>>>> a) you could change the model so words know their parent (in my case, >>>>> Iâm using a 3rd party model for Flashcards, and they just donât know >>>>> this - and adapting them would be a nuisance >>>>> b) my TestPresenter could listen to announcements on the WordPresenter >>>>> - and I could get some communications between presenters (although >>>>> normally the Presenters just get events from Views, and pure domain >>>>> models - so it feels a bit abnormal to consider another Presenter as a >>>>> sort of model - but I could live with this >>>>> c) given the composable nature of views/presenters (and CP is base on a >>>>> WebComponent model) - you could bubble up Announcements, so that if an >>>>> event isnât handled by a viewâs immediate presenter, you could re-route >>>>> it to the parent of the View (the component owner) and see if itâs >>>>> presenter could do something. >>>>> >>>>> >>>>> I think (c) has a certain expectation to it - in fact when I converted >>>>> my initial one-presenter attempt into components, I still had listener >>>>> code in my TestPresenter that was expecting to get a deleteWord >>>>> announcement and I was initially surprised that I wasnât getting it (as >>>>> it was now just going to the Word component I had refactored out). >>>>> >>>>> So I wonder if others here would expect things to work this way too >>>>> (and are there other examples in the wild that lead you here - or scare >>>>> you away from this?). >>>>> >>>>> Back to my Announcement question - if C is a good idea - why doesnât >>>>> the Announcer class let you check if if will handle a particular >>>>> announcement? The API has #hasSubscriber: and #hasSubscriberClass: , >>>>> but its missing: >>>>> >>>>> hasSubscriptionsHandling: anAnnouncement >>>>> "Answer true if I have any subcribers to anAnnouncement" >>>>> >>>>> ^(registry subscriptionsHandling: anAnnouncement ) notEmpty >>>>> >>>>> >>>>> And I am wondering if this is because it's a bad thing to expect to be >>>>> able to check? In my case above, I would want to do this to know if CP >>>>> should instead try announcing a message to a parent presenter because >>>>> the current presenter wonât handle it. In my example above, my >>>>> WordComponentView will broadcast that the delete button was clicked, >>>>> but its actually a parent view which would reasonably want to listen to >>>>> this kind of event and process the delete. And in a many words >>>>> scenario (the Test has many words), its unrealistic for the parent to >>>>> register to listen to each word component individually (in fact CP sort >>>>> of hides this from you), however if you could listen to an event in >>>>> your TestView, it seems to come out quite nicely - and looks a bit >>>>> like this: >>>>> >>>>> viewCreated >>>>> super viewCreated. >>>>> >>>>> self view >>>>> when: CpNavigationAnnouncement >>>>> do: [ :action | self model goto: action location ]; >>>>> >>>>> when: CpAddWordAnnouncement do: [ :action | self addWord: action data >>>>> ]; >>>>> when: CpDeleteWordAnnouncement do: [ :action | self deleteWord: >>>>> action data ]. <â this is the one Iâm talking about >>>>> >>>>> >>>>> So Iâm curious on the overall thought process here, but in particular >>>>> whether I should even submit a PR on Announcer for >>>>> #hasSubscriptionsHandling: ? >>>>> >>>>> Tim >>>>>

April 27, 2021

Re: creating a subclass in system browser

by kmo

/ a red circled exclamation point (hovering says 'Refactorings' - which has a menu for the +New subclass./ That sounds completely horrible. Surely that's never going to remain in the official release. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 27, 2021

Re: creating a subclass in system browser

by kmo

This shows the browser button for a subclass on Pharo 9 on Linux (not the very latest Version 9 by the way). It only appears when you have the class definition tab selected. I hope this shows up - I posted it earlier but it just hasn't appeared in the list - so I'm posting it again. With my luck it will probably appear twice now. <http://forum.world.st/file/t368903/subclassbutton.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 27, 2021

Re: Announcements - and whether its bad to check if a subscription would be handled?

by Richard Sargent

I have seen something called upcasting and downcasting (as contrasted with broadcasting). Mostly, I have seen it in UI layers. e.g. a leaf node receives a change notification, decides it isn't interested in handling the notification, and so passes it up to its parent, etc. Downcasting is similar but in the opposite direction. e.g. a window receives an event and asks its children to handle it, and they do the same. In this case especially, the one that handles the event needs to mark it as handled so that no one else is asked to handle it. On April 27, 2021 5:49:56 AM HST, Tim Mackinnon <tim(a)testit.works> wrote: >Hi guys - yes that fire and forget was always how I had viewed >announcements, and potentially my scenario is misusing "announcements" >which is why I was interested in views here. > >However - as announcements are typically a mechanism for farming out >processing to others - how does one handle the scenario that you might >only want one object to handle the announcement (and not others)? > >in my specific example, with MVP - a view, totally decoupled in a web >browser, wants to pass on a button click to a presenter - however it >not clear what the best mechanism to bubble up that handling should be? >If the immediate presenter of the view can handle it - great - but if >not, how would you continue to broadcast wider to see if someone higher >up the parent component chain can handle it? > >If you go fire and forget (which is how I had viewed announcements >prior to this specific case) - then you have the problem a different >way - when someone processes an announcement it might already have been >handled earlier and so the consumer either has to check first, or their >work is simply ignored as the announcement payload could just filter a >response out. > >In my head, I'm sort of thinking this is akin to CPU interrupt chaining >- where an interrupt can cascade up a stack if not handled OR like >object inheritance where an object can choose to override a message and >stop it from cascading up the inheritance chain. > >Maybe announcements aren't intended for this at all - although it seems >an elegant way to handle it - with just 1 method addition to Announcer >(but it does slightly expose things - albeit in a structured way - and >similar to the similar #hasSubscriber:). > >I'm sure it "depends" - but interested in other observations from the >field, as I'm sure I'm not the first person to hit something like this. > >Tim > >On Tue, 27 Apr 2021, at 3:51 PM, Sven Van Caekenberghe wrote: >> The whole idea is to decouple producers and consumers, like in >> messaging systems. >> >> You should not care if there are other listening, just like the >> listeners should not care if there is someone posting data. >> >> Asking for subscribers is introducing a coupling. >> >> The announcement mechanism will/should deal with this in an efficient >way. >> >> > On 27 Apr 2021, at 16:03, Tim Mackinnon <tim(a)testit.works> wrote: >> > >> > From my rather long ramble below - I am still curious if its >distasteful to have a method on Announcer >> > >> > hasSubscriptionsHandling: anAnnouncement >> > "Answer true if I have any subscribers to anAnnouncement" >> > >> > ^(registry subscriptionsHandling: anAnnouncement ) notEmpty >> > >> > Tim >> > >> > On Thu, 22 Apr 2021, at 11:34 PM, Tim Mackinnon wrote: >> >> Hi everyone - Iâve always thought the article on announcements >many >> >> years ago was very cool - and we donât seem to use them as much as >we >> >> could (but equally they arenât a panacea to be overused everywhere > >> >> either - and they do get used in Pharo to some extent). >> >> >> >> Anyway, Iâve been playing around with CodeParadise (CP is a very >cool >> >> project, and Erik is very supportive and thinking about how to >write >> >> web apps a different wayâ¦ Iâm fascinated), >> >> >> >> And - CP uses announcements as mechanism to send events from the >View >> >> Client (in a web browser) to a Presenter on the server (which >makes >> >> total sense). >> >> >> >> In taking things for a spin, I hit an interesting problem on how >in a >> >> web component world, you should display a spelling test of words - > >> >> >> >> e.g. SpellingTest â has many â> SpellingWord(s). >> >> >> >> >> >> Initially I bunged it all in a single presenter with its >associated >> >> view, and it was a bit messy, and Erik guided me down a route >(that CP >> >> nicely supports) - that my SpellingTest view should have the >name/date >> >> of the test as well as an add word input field, but the list of >current >> >> Words (which I had bunged into a table) - were actually more >elegant as >> >> sub-components - hence a WordView - which renders a single word in >a >> >> DIV, and for the edit screen I was creating, a Delete button next >to >> >> the word (so you could delete it). So a 1 to many relationship >> >> essentials. >> >> >> >> This is where the announcements kick in (and lead to my ultimate >question). >> >> >> >> When you click the Delete button, if I use a sub component - my >view >> >> will generate a DeleteWordAnnouncement - which gets fed to my >> >> SpellingWordPresenter - however words in this sense donât >naturally >> >> know their parent (the SpellingTest) - and its the parent test >that has >> >> a #deleteWord: method. >> >> >> >> Iâve been taking with Erik, on different ways to elegantly handle >this. >> >> >> >> a) you could change the model so words know their parent (in my >case, >> >> Iâm using a 3rd party model for Flashcards, and they just donât >know >> >> this - and adapting them would be a nuisance >> >> b) my TestPresenter could listen to announcements on the >WordPresenter >> >> - and I could get some communications between presenters (although > >> >> normally the Presenters just get events from Views, and pure >domain >> >> models - so it feels a bit abnormal to consider another Presenter >as a >> >> sort of model - but I could live with this >> >> c) given the composable nature of views/presenters (and CP is base >on a >> >> WebComponent model) - you could bubble up Announcements, so that >if an >> >> event isnât handled by a viewâs immediate presenter, you could >re-route >> >> it to the parent of the View (the component owner) and see if itâs > >> >> presenter could do something. >> >> >> >> >> >> I think (c) has a certain expectation to it - in fact when I >converted >> >> my initial one-presenter attempt into components, I still had >listener >> >> code in my TestPresenter that was expecting to get a deleteWord >> >> announcement and I was initially surprised that I wasnât getting >it (as >> >> it was now just going to the Word component I had refactored out). > >> >> >> >> So I wonder if others here would expect things to work this way >too >> >> (and are there other examples in the wild that lead you here - or >scare >> >> you away from this?). >> >> >> >> Back to my Announcement question - if C is a good idea - why >doesnât >> >> the Announcer class let you check if if will handle a particular >> >> announcement? The API has #hasSubscriber: and >#hasSubscriberClass: , >> >> but its missing: >> >> >> >> hasSubscriptionsHandling: anAnnouncement >> >> "Answer true if I have any subcribers to anAnnouncement" >> >> >> >> ^(registry subscriptionsHandling: anAnnouncement ) notEmpty >> >> >> >> >> >> And I am wondering if this is because it's a bad thing to expect >to be >> >> able to check? In my case above, I would want to do this to know >if CP >> >> should instead try announcing a message to a parent presenter >because >> >> the current presenter wonât handle it. In my example above, my >> >> WordComponentView will broadcast that the delete button was >clicked, >> >> but its actually a parent view which would reasonably want to >listen to >> >> this kind of event and process the delete. And in a many words >> >> scenario (the Test has many words), its unrealistic for the parent >to >> >> register to listen to each word component individually (in fact CP >sort >> >> of hides this from you), however if you could listen to an event >in >> >> your TestView, it seems to come out quite nicely - and looks a >bit >> >> like this: >> >> >> >> viewCreated >> >> super viewCreated. >> >> >> >> self view >> >> when: CpNavigationAnnouncement >> >> do: [ :action | self model goto: action location ]; >> >> >> >> when: CpAddWordAnnouncement do: [ :action | self addWord: action >data >> >> ]; >> >> when: CpDeleteWordAnnouncement do: [ :action | self deleteWord: >> >> action data ]. <â this is the one Iâm talking about >> >> >> >> >> >> So Iâm curious on the overall thought process here, but in >particular >> >> whether I should even submit a PR on Announcer for >> >> #hasSubscriptionsHandling: ? >> >> >> >> Tim >> >> >> >> >>

April 27, 2021

Re: creating a subclass in system browser

by Russ Whaley

Ah, in my v9 version, I see a red circled exclamation point (hovering says 'Refactorings' - which has a menu for the +New subclass. Good to know! Thanks! On Tue, Apr 27, 2021 at 12:17 PM kmo <voxkmp(a)gmail.com> wrote: > I've attached a screenshot. The button appears when you select the class > definition tab in the browser. Press it and you get a dialog to enter a > subclass name then the text > <http://forum.world.st/file/t368903/subclassbutton.png> template for that > subclass appears in the browser class definition tab. > > This is from Pharo 9 on Linux (this is an older version 9 - not the very > latest) > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -- Russ Whaley whaley.russ(a)gmail.com

April 27, 2021