__gc visible to lua code...

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: __gc visible to lua code...

Michael Broughton
Graham,

I have been working on a library this last week, and I just did some experimenting with separating my metatable and method table, as suggested by Rici Lake. It made my library a few lines longer, but it is mostly unchanged.

As expected, none of the metamethods are accessible from the Lua side anymore. For example, you can do these:

#udata
udata:close()
u3 = u1 + u2

But not these:

udata:__len()
udata:__gc()
u3 = u1:__add(u2)

This is the behavior you want, right? I'll post my library, if you want an example. I just need to write some documentation first.

Mike


Graham Wakefield wrote:
Having a close() method may be a good idea for many uses of userdata, where freeing resources referred by the userdata can be independent of the userdata lifetime. In such cases, it makes sense to test against NULL for the userdata contents, etc. Calling udata:close() won't set the udata to nil, won't free the userdata itself, since this is under the control of the garbage collector.

But this is irrelevant to __gc. The __gc metamethod, as far as I understand, is supposed to be a kind of callback into C to let you know that the userdata has been collected, so you can free additional resources if necessary. It makes no sense to expose this method to Lua code.
Using __gc as a close() method confuses two distinct purposes.


Reply | Threaded
Open this post in threaded view
|

RE: __gc visible to lua code...

Vijay Aswadhati
On Saturday, March 31, 2007 8:54 AM, Michael Broughton wrote:

> Graham,
> 
> I have been working on a library this last week, and I just did some
> experimenting with separating my metatable and method table, as suggested
> by Rici Lake. It made my library a few lines longer, but it is mostly
> unchanged.   
> 
> As expected, none of the metamethods are accessible from the Lua side
> anymore. For example, you can do these: 
> 
> #udata
> udata:close()
> u3 = u1 + u2
> 
> But not these:
> 
> udata:__len()
> udata:__gc()
> u3 = u1:__add(u2)
> 
> This is the behavior you want, right? I'll post my library, if you want an
> example. I just need to write some documentation first. 
> 
> Mike
> 

I am interested in taking a peek. Will look forward to your post. Thanks.

-- Vijay



Reply | Threaded
Open this post in threaded view
|

Re: __gc visible to lua code...

Graham Wakefield
In reply to this post by Michael Broughton
Yes, certainly I'd love to try it.

On Mar 31, 2007, at 8:54 AM, Michael Broughton wrote:

Graham,

I have been working on a library this last week, and I just did some experimenting with separating my metatable and method table, as suggested by Rici Lake. It made my library a few lines longer, but it is mostly unchanged.

As expected, none of the metamethods are accessible from the Lua side anymore. For example, you can do these:

#udata
udata:close()
u3 = u1 + u2

But not these:

udata:__len()
udata:__gc()
u3 = u1:__add(u2)

This is the behavior you want, right? I'll post my library, if you want an example. I just need to write some documentation first.

Mike


Graham Wakefield wrote:
Having a close() method may be a good idea for many uses of userdata, where freeing resources referred by the userdata can be independent of the userdata lifetime.  In such cases, it makes sense to test against NULL for the userdata contents, etc.  Calling udata:close() won't set the udata to nil, won't free the userdata itself, since this is under the control of the garbage collector.

But this is irrelevant to __gc.  The __gc metamethod, as far as I understand, is supposed to be a kind of callback into C to let you know that the userdata has been collected, so you can free additional resources if necessary.  It makes no sense to expose this method to Lua code.   
Using __gc as a close() method confuses two distinct purposes.


grrr waaa
www.grahamwakefield.net




Reply | Threaded
Open this post in threaded view
|

Re: __gc visible to lua code...

Sam Roberts-2
In reply to this post by Graham Wakefield
On Sat, Mar 31, 2007 at 02:47:00AM -0700, Graham Wakefield wrote:
> But this is irrelevant to __gc.  The __gc metamethod, as far as I  
> understand, is supposed to be a kind of callback into C to let you  
> know that the userdata has been collected, so you can free additional  
> resources if necessary.  It makes no sense to expose this method to  
> Lua code.

The close() was only one example of when __gc is useful from lua, its
easy to think of others, like replacing __gc with a hook that frees
other resources inside lua, and then calls the original __gc. And
there's nothing about __gc that requires it to be callback into C, its
just a notification by the garbage collector that an object is no longer
referenced by lua, you can use that notification for whatever purpose
you want.

Lua implements language mechanisms, how you use those mechanisms is up
to you. If you don't want your metatable messed with from lua, lua even
has a mechanism you can use to hide it, you can even hide specific items
in the metatable.

Languages that try too hard to prevent us from slipping also prevent us
from achieving, lua is not such a language.

Cheers,
Sam


12