Smalltalk › Pharo › Pharo Smalltalk Developers

Strategies with Nautilus announcements

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Uko2

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

Nicolai Hess

Re: Strategies with Nautilus announcements

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[hidden email]>:

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

what do you think?

Uko

Uko2

Re: Strategies with Nautilus announcements

On 12 Sep 2015, at 17:34, Nicolai Hess <[hidden email]> wrote:

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[hidden email]>:
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

stepharo

Re: Strategies with Nautilus announcements

>> 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

Henrik Sperre Johansen

Re: Strategies with Nautilus announcements

In reply to this post by Uko2

On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <[hidden email]> wrote:

On 12 Sep 2015, at 17:34, Nicolai Hess <[hidden email]> wrote:

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[hidden email]>:
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

signature.asc (859 bytes) Download Attachment

Uko2

Re: Strategies with Nautilus announcements

On 13 Sep 2015, at 11:59, Henrik Johansen <[hidden email]> wrote:

On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <[hidden email]> wrote:

On 12 Sep 2015, at 17:34, Nicolai Hess <[hidden email]> wrote:

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[hidden email]>:
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

Henrik Sperre Johansen

Re: Strategies with Nautilus announcements

On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <[hidden email]> wrote:

On 13 Sep 2015, at 11:59, Henrik Johansen <[hidden email]> wrote:

On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <[hidden email]> wrote:

On 12 Sep 2015, at 17:34, Nicolai Hess <[hidden email]> wrote:

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[hidden email]>:
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

signature.asc (859 bytes) Download Attachment

Uko2

Re: Strategies with Nautilus announcements

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 <[hidden email]> wrote:

On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <[hidden email]> wrote:

On 13 Sep 2015, at 11:59, Henrik Johansen <[hidden email]> wrote:

On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <[hidden email]> wrote:

On 12 Sep 2015, at 17:34, Nicolai Hess <[hidden email]> wrote:

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[hidden email]>:
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

Henrik Sperre Johansen

Re: Strategies with Nautilus announcements

In reply to this post by Henrik Sperre Johansen

On 13 Sep 2015, at 12:06 , Henrik Johansen <[hidden email]> wrote:

On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <[hidden email]> wrote:

On 13 Sep 2015, at 11:59, Henrik Johansen <[hidden email]> wrote:

On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <[hidden email]> wrote:

On 12 Sep 2015, at 17:34, Nicolai Hess <[hidden email]> wrote:

2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <[hidden email]>:
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 (859 bytes) Download Attachment

Henrik Sperre Johansen

Re: Strategies with Nautilus announcements

In reply to this post by Uko2

> On 13 Sep 2015, at 12:15 , Yuriy Tymchuk <[hidden email]> 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

signature.asc (859 bytes) Download Attachment