Strategies with Nautilus announcements
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)? Uko
2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
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 ...) What we could do (maybe this is a bit overkill): - make an announcements hierarchy (NautilusPackageAnnouncement -> NautiulusClassAnnouncement ...) but never subscribe to this Announcemnts - create sub classes for every "kind" NautilusPackageAnnouncement subclass: NautilusPackageChangedAnnouncement NautilusPackageAnnouncement subclass: NautilusPackageSelectedAnnouncement NautilusClassAnnouncement subclass: NautilusClassSelectedAnnouncement NautilusClassAnnouncement subclass: NautilusClassChangedAnnouncement And only subscribe to this subclasses. That way we are using the hierarchy of Announcement classes for removing of duplicated code, but only register and announce the "leaf"-nodes (NautilusClassChangedAnnouncement / NautilusPackageChangedAnnouncement...) what do you think?
Uko
On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess@web.de> wrote:
2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: 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â.
What we could do (maybe this is a bit overkill):
- make an announcements hierarchy (NautilusPackageAnnouncement -> NautiulusClassAnnouncement ...) but never subscribe to this Announcemnts - create sub classes for every "kind" NautilusPackageAnnouncement subclass: NautilusPackageChangedAnnouncement NautilusPackageAnnouncement subclass: NautilusPackageSelectedAnnouncement
NautilusClassAnnouncement subclass: NautilusClassSelectedAnnouncement NautilusClassAnnouncement subclass: NautilusClassChangedAnnouncement
And only subscribe to this subclasses. That way we are using the hierarchy of Announcement classes for removing of duplicated code, but only register and announce the "leaf"-nodes (NautilusClassChangedAnnouncement / NautilusPackageChangedAnnouncement...)
what do you think?
This may do. Also another option would be to have a NautilusSelectionAnnouncement with all 4 attributes, and then just subclass it for a different type. Uko
Uko
What we could do (maybe this is a bit overkill):
- make an announcements hierarchy (NautilusPackageAnnouncement -> NautiulusClassAnnouncement ...) but never subscribe to this Announcemnts - create sub classes for every "kind" NautilusPackageAnnouncement subclass: NautilusPackageChangedAnnouncement NautilusPackageAnnouncement subclass: NautilusPackageSelectedAnnouncement
NautilusClassAnnouncement subclass: NautilusClassSelectedAnnouncement NautilusClassAnnouncement subclass: NautilusClassChangedAnnouncement
And only subscribe to this subclasses. That way we are using the hierarchy of Announcement classes for removing of duplicated code, but only register and announce the "leaf"-nodes (NautilusClassChangedAnnouncement / NautilusPackageChangedAnnouncement...)
what do you think?
This may do. Also another option would be to have a NautilusSelectionAnnouncement with all 4 attributes, and then just subclass it for a different type.
Yes this solution is less verbose and has my preference. stef
On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: 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... Cheers, Henry
On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: 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
Cheers, Henry
On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: 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
I donât care about other dialects. Iâm not changing anything now. Iâm just saying: âhere is a limitation, maybe it can be solved in this wayâ. Maybe there is a real reason for that. But nobody answers. Uko
On 13 Sep 2015, at 12:06, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: 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
On 13 Sep 2015, at 12:15 , Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
I donât care about other dialects. Iâm not changing anything now. Iâm just saying: âhere is a limitation, maybe it can be solved in this wayâ. Maybe there is a real reason for that. But nobody answers.
Uko
And I'm telling you, it's not the limitation that's wrong, it's the use. If you want a hierarchy like: SelectionChanged ClassChanged ProtocolChanged MethodChanged to work, you use double dispatch. myThing when: SelectionChanged do: [:ann ann handleBy: self ] ClassChanged >> #handleBy: aResponder aResponder classChanged: ann ProtocolChanged aResponder protoclChanged: ann etc. You do *not* respond to each specifically when ClassChanged do: [:ann self classChanged: ann] Cheers, Henry
On 13 Sep 2015, at 12:06 , Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: 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?
participants (4)
-
Henrik Johansen -
Nicolai Hess -
stepharo -
Yuriy Tymchuk