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 wrote:
> I appreciate the further thoughts of others - I should go back and look
> at
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
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
The MVP scenario you describe with “bubbling up” of event handling is how
Dolphin implements command routing in MVP. I’d suggest that what you need is an
implementation of this, which is a separate mechanism to Announcements.
Possibly your suggested solution is a clever way to implement a
The bubbling up is very common in UI, I don't know how it is implemented
though.
I don't know if event handling is programmed using events or imperative
calls to continue "bubbling" up, or... the event is handler by the
container presenter and passed down to the target (e.g. a button).
So the end
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
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
Exceptions are real, so your use case might justify it.
In my experience I never had to test whether an announcer has some
subscription, and before using announcements whether an object has some
"listener" to some event.
I always saw announcements as a fire and forget kind of architecture.
Not
>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,
