Object.notifyRegister

Lutger Joined: 05/25/06 Posts: 13

Posted: 03/23/07 14:49:32 Hi, I see that Object.notifyRegister and notifyUnRegister are currently commented out in Tango. Will they be added in the future or is there a different mechanism to get the same functionality? I've looked into phobos source but it depends on something defined in internal/mars.c, I'd rather not touch that myself. I would like to get my signal-slots working in Tango. On a related note: is it possible in Tango to retrieve from a the .ptr property of a delegate whether it originates from an Object? It seems that checking with gc.getAttr() if this was allocated by the garbage collector does so, but that depends on all other delegates being stack allocated? Thanks.

Author	Message
sean Joined: 06/24/04 Posts: 109	Posted: 03/23/07 19:09:23 notifyRegister and notifyUnRegsiter are commented out because we hadn't developed a signal/slot mechanism yet and weren't sure if they would actually be needed. Are there other ways that the same thing could be accomplished? I just want to explore alternatives before re-enabling that functionality. As for your second question, it sounds like you want to determine whether a delegate is tied to an object rather than being nested within a free function, etc? The best way would probably be to do "gc.getAttr(p) | GC.FINALIZE" but this still doesn't account for objects constructed via a custom allocator. Still, the GC is the only mechanism I can think of that actually tracks this sort of thing.
Lutger Joined: 05/25/06 Posts: 13	Posted: 03/24/07 02:19:45 I am not aware of any (better) alternatives. The stumbling block in D, or at least for me, was that you cannot rely on destructors as in C++. Bartosz Milewski mentioned some things about a reference counting / resource management mechanism in D, although I haven't seen any comments from Walter Bright about it. Perhaps that will enable a more general solution if it will ever be implemented. What I did in a previous implementation, before the notify functions were implemented, was to have some global structure where signals and slots could set their, and query each others state (alive or not), quite a hack. As for getAttr(), the thing I want to do is enable such syntax as in phobos signals, but not restrict slots to member functions. That is, my code should be able to determine if it is safe to treat the .ptr property of a delegate as a reference to an Object and not segfault on delegate literals (this happens in phobos). Actually it's fine if only Objects allocated by the GC are recognized as such. I think it is reasonable for custom allocated objects to require handling of disconnections manually.
sean Joined: 06/24/04 Posts: 109	Posted: 03/26/07 07:54:15 For what it's worth, notifyUnRegister is called when the object dtor is called, so it isn't any more reliable than using a dtor. Its benefit is simply that you can hook object destruction in mixin code.
Lutger Joined: 05/25/06 Posts: 13	Posted: 03/27/07 13:07:38 I take it you mean notifyRegister? The benefit of this is more than for mixin code. In a signal slot design, you want to remove all references (which must be weak pointers) to an Object automatically when that object gets destroyed. Without notifyRegister, you have to somehow store a handle to a signal in the slot, which means: 1) the user needs to modify her classes 2) you need to remove the handle to the signal in a slot when the signal gets destroyed 3) all these handles need to be weak pointers, the GC must not see them or you will get cyclic references notifyRegister and notifyUnRegister were specifically added by Walter for signal-slots iirc. Without them or something equivalent it is very awkard to program this design, as far as I know. Note that regarding to 1), signals in D do better than both QT and boost::signals where you cannot use member functions of classes for managed connections without modification.
sean Joined: 06/24/04 Posts: 109	Posted: 03/27/07 19:44:00 Thanks for the explanation. That makes a lot of sense :-)