Selene comparisons in wiki

[jeremyong]

Hey,

Thanks for writing the comparison to the Selene library! I thought I'd clarify a few points:

1. There are actually two ways to register objects with Selene. One is to let lua construct the object and destroy it upon garbage collection. Another is to create the object in C++ and handle its lifetime yourself.
2. There are more types you can pass in function parameters than just the primitives you listed. You can pass pointers and references to arbitrary types too.
3. You can in fact yield from functions with coroutines (https://github.com/jeremyong/Selene/blob/master/test/interop_tests.h)
4. Lifetime policy with classes registered in Selene are also clear (leverages __gc probably much like yours does)
5. There is pretty extensive test coverage in Selene (https://github.com/jeremyong/Selene/blob/master/test/Test.cpp) and it is also tested via Travis.

Cheers, J

[davidsiaw]

Hi, thanks for writing to clarify these points.

About No. 1 and 4, thanks for clearing up the fact that objects created in C++ are owned exclusively by C++. This means you have to provide deletor functions should you want to give ownership of objects to your script.

It is not obvious that:

void AddFoo(sel::State& s)
{
  Foo foo(2);
  state["foo"].SetObj(foo);
}

foo will go out of scope, destruct, and the reference becomes invalid. Any accesses to it might segfault.

In my library you are required to call lua.CreateUserdata(new T()) that wraps a pointer to your object, which your library does implicitly.

Admittedly, someone could pass a pointer to T to lua.CreateUserdata() that he could delete later, but this means that the person needs to consciously delete the pointer, or knowingly not pass ownership of the pointer to Lua.

In the event that no more references to the LuaUserdata exist in both C++ and Lua, the __gc will collect T and delete T properly.

About No. 3, I am saying I can yield coroutines from C++. I have edited the doc to clarify. You can of course, yield at any time in Lua. That is easy

I hope you don't take this personally, I find it helpful to sound my programs' features against another similar one to understand better what mine lacks and what mine can do without.

[jeremyong]

Nope I don't take it personally at all. It's great to see the work others do as you've said and I think the writeup is useful.

I understand what you mean by "implicit lifetime" now. It's implicit as much as stack removal would be implicit I suppose. The goal is a strict coupling between C++ lifetime and Lua lifetime. If it dies on one side, it should die on the other and vice versa.

Interesting that you chose to allowed yielding from C++. I haven't added this because it can make the call stack a bit challenging to read, but I might consider it again now.

[davidsiaw]

If there is nothing further to add I'll close this ticket