Support for Lua 4 _close variables about luabridge3 HOT 14 CLOSED

It should be allowed in luabridge3, but not in 2

from luabridge3.

Have you tried registering a "__close" method ? Or you want the destructor to run ? What about if you stored local references ?

Will investigate how we could use it.

from luabridge3.

The short answer to your question is that I have not tried it. I notice that __close is listed in LB3's is_metamethod function, which leads me to think it won't work on LB3 at least.

I definitely do not want the dtor to run. The __close function is a method on the class that releases expensive resources. If the variable is defined lua <close> Lua 5.4 automatically calls it when the variable goes out of scope on the block or chunk where it is defined. For example, if your class is accessing a database and has a large database result, you don't want to wait for gc to release it. So your class could register a __close function that releases it the moment the class variable in Lua goes out of scope.

from luabridge3.

It looks like all I have to do is register a __close method. This works in both LB2 and LB3. I am closing this issue.

from luabridge3.

I'm reopening this issue, because there is no support for this scenario:

struct foobase
{
   void close_func() {}
};

struct foo : foobase {};

luabridge::getGlobalNamespace(L)
   .beginNamespace("foobar")
      .beginClass<foobase>("foobase")
         .addFunction("__close", &foobase::close_func)
      .endClass()
      .deriveClass<foo, foobase>("foo")
         .addConstructor<void(*)()>()
      .endClass()
   .endNamespace();

Basically, the problem is that Lua does not find the close function in the base class. So this code:

local foo <close> foobar.foo()

gets runtime error "variable 'foo' got a non-closable value"

from luabridge3.

Another issue is if we are going to support base-class close functions, there probably needs to be a way for a subclass to refuse it. One way might be:

struct bar : foobase
{
   void do_nothing() {} // <-- register this as "__close" and then bar is safe from dangerous subclass close func.
}

However, it would be better if no close function were registered for these sub-classes. Then Lua would give a proper error message.

from luabridge3.

Have you tried simulating inheritance with metatables in plain lua to see if the problem is there already ? I will look deeply into luabridge inheritance with deriveClass and metamethods visibility. I suspect we might need to register a custom close metamethod that does search upwards in the hierarchy chain, much like index_metamethod does.

from luabridge3.

My guess is the problem is already there in Lua, but I haven't tried to do it. My plain Lua API chops are rudimentary, thanks to you and your predecessors' work. 😄

from luabridge3.

This is a lua issue, __close needs to be present in the metatable of the object being decorated with <close>. Lua doesn't even try to call __index to resolve the metamethods, so the new class indeed has no __close in the metatable and then it errors variable 'foo' got a non-closable value before we can reach control. So the only way is to have LB3 to ALWAYS register a __close metamethod and allow each class to register with a addCloseFallbackMetamethod (much like we do for the index and new index fallback) which will be executed if present or traverse the hierarchy in search for other __close metamethods in parents... uhmpf, seems way too convoluted for really little effort, will maybe leave it as it is, you can register the __close metamethod for the classes you need explicitly. Much easier and with much greater flexibility.

from luabridge3.

Yikes. I don't mind explicitly add a function binding to the classes for __close. The problem is (in the example) class foo does not contain a close function. The close function is in foobase. In a real situation we are talking about classes that are difficult or impossible to modify, so adding wrapper close functions is a challenge. Maybe it could be done with a proxy.

from luabridge3.

I think we might have the same issue with other metamethods. As metamethods are not looked up via __index, registering for example __add in the base class is not "seen" by derived classes. This means that even for supporting that case, luabridge will need to assume all metamethods would be inherited by derived classes and would need to register custom ones all along the chain, doing what we do in our custom __index where we traverse the inheritance list upwards looking for an implementation.

from luabridge3.

I'm not looking for LB to do any Lua magic. I think something like the following would be sufficient:

luabridge::getGlobalNamespace(L)
   .beginNamespace("foobar")
      .beginClass<foobase>("foobase")
         .addFunction("__close", &foobase::close_func)
      .endClass()
      .deriveClass<foo, foobase>("foo")
         .addConstructor<void(*)()>()
         .addFunction("__close", &foobase::close_func)  // <-- currently not allowed, I believe
      .endClass()
   .endNamespace();

Otherwise, every derived class that wants to close has to implement a proxy to call foobase::close_func.

from luabridge3.

Is there anything that needs to be done for this one ?

from luabridge3.

I think we've covered it. I'll open a new one if I run into any other issues.

from luabridge3.