> On 13 Sep 2015, at 12:06 , Henrik Johansen <[email protected]> > wrote: > >> >> On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On 13 Sep 2015, at 11:59, Henrik Johansen <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On 12 Sep 2015, at 17:34, Nicolai Hess <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> >>>>> 2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[email protected] >>>>> <mailto:[email protected]>>: >>>>> Hi, >>>>> >>>>> as NautilusMethodSelected contains also an information about protocol, >>>>> class, package; >>>>> NautilusProtocolSelected contains an information about class and package; >>>>> . >>>>> . >>>>> . >>>>> >>>>> I’ve inherited NautilusClassSelected from NautilusPackageSelected and >>>>> NautilusProtocolSelected from NautilusClassSelected… to remove >>>>> duplication. But as announcement subscription also includes it’s >>>>> subclasses, if you subscribe to NautilusPackageSelected, you end up >>>>> receiving also NautilusClassSelected, NautilusProtocolSelected and >>>>> NautilusMethodSelected. >>>>> >>>>> What is a good way to resolve this (I can simply separate all the >>>>> classes, but maybe there is something important from conceptual point of >>>>> view)? >>>>> >>>>> I didn't know announcments are working that way, but it may make sense if >>>>> you want to group announcments (register once for "WindowAnnouncement" >>>>> and receiving all kind of >>>>> subannouncements (WindowClosed/WindowOpened …) >>>> >>>> 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?
signature.asc
Description: Message signed with OpenPGP using GPGMail
