auto classes and finalizers

[Sean Kelly]

Sean Kelly wrote:
> Mike Capp wrote:
>> In article <e2378s$gpn$1 at digitaldaemon.com>, Sean Kelly says...
>>> the next release [of Ares] will include a hookable callback in the 
>>> standard library similar to onAssertError. This will allow the user 
>>> to decide upon which behavior is most appropriate, and to do so on a 
>>> per-class basis as I am planning to pass either the original class 
>>> pointer or simply a ClassInfo object.
>>
>> To clarify: if the decision is per-class (which I agree it should be), 
>> is there
>> any benefit to catching this error at runtime rather than compile 
>> time? Or is it
>> just that it's easier to try out this way?

As per Kris' suggestion, the (future) behavior of onCollectResource in 
Ares has changed slightly.  The call now has the following format:

     extern (C) bool onCollectResource( Object obj );

Default behavior is as before--to silently clean up the object and 
continue.  However, if the user has supplied a cleanup handler and it 
returns 'false' then the object's dtors will not be called.  Instead, 
the user code is expected to have cleaned things up another way.  Thus 
the user has a selection of options to choose from, in order of complexity:

* Report the error and continue, returning 'true'.
* Report the error and terminate the application.
* Clean up the object's resources by some other means and return 'false'.

The final option is to allow the user to write dtors that always assume 
referenced objects are valid while allowing execution to continue if 
such objects are encountered by the garbage collector (currently, 
dereferencing a GCed object in a dtor may cause an access violation if 
the refrenced object has already been cleaned up).  I'll admit that this 
last option provides a lot more rope than seems prudent, but it also 
makes for some interesting possibilities and I'm curious to see how 
things work out :-)


Sean