Re: Tool class (Long... *real* Long)

[glen e. p. ropella]

Theodore C. Belding writes:
 > >   (2) Who, agent A or agent B or ???,  has the
 > >       responsibility for dropping the shared object X?
 > 
 > Sounds like a classic place to use reference counting or reference-counted
 > smart pointers.  See:
 > Meyers, S. (1996). More Effective C++. Addison-Wesley. pp. 183-213.
 > or
 > Barton, J. J., and L. R. Nackman (1994). Scientific and Engineering C++.
 > Addison-Wesley. p. 425
 > 
 > (Both are C++-specific, but the concept is general.  Maybe someone else can
 > suggest a more general reference.)  Of course, you could also just use
 > garbage collection, if it is available.

This sounds like a job for our new addRef capability in 
DefObject.  Unfortunately, it's incomplete.  Every object
is capable of containing any number of dependency refs to
other objects.  The capability was intended to be used 
for dropping so that if an object is dropped that has
dependency references to other objects, then those other
objects will be notified.  But, I don't see why it couldn't
be used the other way, namely, an object perusing its own 
reference list checking if there are any valid users left
using it.

For instance, in this tool class, a new user will send the
message [screwDriver addRef: mynotifyfunction
               withArgument: (void *)screwDriver];

Then the mynotifyfunction can be defined such that, if called,
it can query the argument (screwDriver, here) as to the purpose
of the notify (state change or deallocation) or whatever.

Of course, now that I talk at it awhile, it sounds like you'd
be abusing the notification mechanism.  Maybe it's better to 
use a customized set of methods for the tool class.

glen