I don���t know about performance, but as far as I understand you can also subscribe to ���WindowAnnouncement withAllSubclasses���.
That would be setting yourself up for a heap of duplicates.
By design, you can subscribe twice to the same announcement and receive two notifications, so doing that will net you $InheritanceLevelsFromWindowAnnouncement copies of each���
My point was that maybe instead of making an implicit inheritance subscription we should make it explicit. So if you want to subscribe only to WindowAnnouncement and not to its subclasses, you can do that. If you wan to subscribe to the hierarchy you can do ���WindowAnnouncement withAllSubclasses���. Again, this is just an idea and I don���t know how it impacts performance or some other things. I just see a limitation now that I cannot subscribe only to a class ignoring it subclasses without doing a check later.
Uko
If you do, you majorly break compatability with how announcements work in all other dialects.
So in that case, better rename the framework at the same time.
Cheers,
Henry
A bit harsh, perhaps.
All frameworks will have considerations built into their designs.
For Announcements, a few of those are:
- Subscription limits are unconstrained. Which means it is *possible* for one recipient to receive multiple copies of the same announcement if that's what needed, and left to the user to avoid if not.
- The Announcement class hierarchy is used to group announcements that should be delivered.
When your use don't conform to those, it's usually better to rewrite your own code in consideration of how the framework works, rather than change the framework.
Cheers,
Henry
P.S. Weren't Traits invented to reduce code duplication across classes?