Re: Unexpected order of __finalize

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