Re: Unexpected order of __finalize

Well that's strange!  Oh wait.. ah ha! I tried your program in an
interactive Lua console, with luabind and found something not very
obvious if you were running this as a complete chunk.

The program is actually failing to completely create a 'B', as there is
no __init() function for it.  So the 'B' finalise gets called, and
because there was an error in the A init, A gets zapped and finalised as
well.  In that order.  The program only makes it to "local a = A()"

It seems to work as expected if you add an init function for B.

Nigel

On Tue, 2010-08-31 at 18:54 -0700, Max McGuire wrote:
> For what it's worth, I was able to make things work the way I expected
> to by storing the environment table for an object instance in the
> global registry (I set it in set_instance_value).  This prevents the
> table from being garbage collected. I remove it from the global
> registry after the __finalize method has been called on the object in
> destroy_instance.
> 
> I'd be interested to hear what the developers have to say about this
> "issue" and fix.
> 
> Max
> 
> --
> Technical Director
> Unknown Worlds Entertainment
> http://www.unknownworlds.com
> 
> 
> On Tue, Aug 31, 2010 at 6:00 PM, Max McGuire <[email protected]>
> wrote:
>         I've run into some unexpected behavior with the __finalize
>         method. Specifically if my class has members that are also
>         classes, the __finalize methods for the members are getting
>         called before the __finalize method for the owner.
>         
>         Here's a simple example:
>         
>         class 'B'
>         
>         function B:__finalize()
>             print("B:__finalize\n")
>         end
>         
>         class 'A'
>         
>         function A:__init()
>             self.b = B()
>         end
>         
>         function A:__finalize()
>             print("A:__finalize\n")
>         end
>         
>         local a = A()
>         a = nil
>         
>         collectgarbage("collect")
>         
>         
>         The output from this program is:
>         
>         B:__finalize
>         A:__finalize
>         
>         
>         This is the opposite behavior that you would get from a C++
>         program and is problematic, especially if B is actually a
>         class implemented in C++ and you tried to access b during the
>         __finalize method for A.
>         
>         Is this by design or am I missing something?
>         
>         Thanks,
>         
>         Max
>         
>         --
>         Technical Director
>         Unknown Worlds Entertainment
>         http://www.unknownworlds.com
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________ luabind-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luabind-user



------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd