Open typemytype opened 7 years ago
I wondering why the order is going from most specific -> least specific?
I just hit this issue with a SelectionChanged notification sent from contour, which the glyph watches then sends its own Glyph.SelectionChanged that destroys the representation.
This problem affects the call to destroyRepresentations in BaseObject since it makes a subscription to all the notifications it sends. This means destructors aren't run first when they absolutely should.
@typesupply Could you explain the rationale for the order of notifications:
I wondering why the order is going from most specific -> least specific?
I expect simply reversing that order should fix this issue.
Edit: Although reversing the order fixes the issue with destroyRepresentations, I think destructors should have some special rooting in NotificationCenter so they're guaranteed to be called first.
Could you explain the rationale for the order of notifications:
I don't remember. That # most specific -> least specific
note is a sign that I had some reason, but I don't know what it was. I'm 100% okay with changing the order and seeing if it breaks anything. I'm also okay with some sort of special destructive pre-run if necessary.
when an object is self observing it is subscribed to all notifications, this makes sense in order to destroy representation factories.
But the order of calling observers puts the self observing as third option. see https://github.com/typesupply/defcon/blob/master/Lib/defcon/tools/notifications.py#L146-L151
This causes issues when a factories has no destructive notifications (aka "
a small example to demonstrate this issue.
I don't have any idea to push self observing notifications upfront. The factories could add all possible notifications but that does not feels right, especially with heavy calculating factories.