Extensible classes support

[kunitoki]

This PR aims at allowing C++ binded classes to be extensible from lua:

    luabridge::getGlobalNamespace(L)
        .beginClass<X>("X", luabridge::extensibleClass)
            .addConstructor<void(*)()>()
        .endClass();

    int result = runLua(R"(
        function X:test()
            return 1
        end

        local x = X()
        result = x:test()
    )");

    assert(result == 1);

[rpatters1]

If a base class sets this option, will all subclasses be extensible as well? (Just trying to understand what is being added.)

[kunitoki]

This is something i'm working on. Extensibility is a class property, so should be enabled in each class individually.

[rpatters1]

Extensibility is a class property, so should be enabled in each class individually.

Yes, I agree. I suppose the better, more precise question is, will subclasses be able to access methods added to one of its base classes (up the hierarchy)?

[kunitoki]

Take a look at the tests https://github.com/kunitoki/LuaBridge3/pull/116/files#diff-cd70549e26a819fe4ab5502e1e783320b16be7b19c74582267b8cc90b73943e7R2684

[rpatters1]

I'm assuming these functions all receive a self parameter. It might be good to include some tests around that.

[kunitoki]

I'm assuming these functions all receive a self parameter. It might be good to include some tests around that.

Definately, this is just the beginning, a lot more tests are needed down there.

[rpatters1]

Another point of clarification. It looks like the answer is "no" but just to confirm:

Does this allow you to replace existing functions that were registered on the class? One of the reasons we added the mixin library was to improve the DX around clunky APIs in the original C++ classes. An example is that the C++ framework has its own homegrown string class, and in order to pass text to any of those classes, you have to stop and create one of the proprietary string types, stuff your text into it, then pass it. The mixin library replaces those methods with methods that take anything it can recognize as a string.

[kunitoki]

I'm thinking this by default should not be allowed (added a check for this here 810813e#diff-a6c1434d943944028ce926611075458078b52d6d2de84188f557c344c3c0fe74R297-R313 which prevents any modification).

But i see the use cases in controlled environments (we might have a use for that as well for the reason you mention). One complication for that feature could be allowing still to access the super() method being wrapped, in order to properly "proxy" it.

[ThistleSifter]

Will this also eventually include the ability to create custom subclasses from extensible classes?

[kunitoki]

Not sure i would mix luabridge inheritance (that works on top of c++ userdata) with mixed one (a lua table which parent is a c++ userdata), mostly because it will overcomplicate key resolution. But contributions are welcome. I suggest we start a discussion on how we would like this to work.

Use composition over inheritance, the world is bad already.

[kunitoki]

Does this allow you to replace existing functions that were registered on the class?

This is now in

LuaBridge3/Tests/Source/ClassTests.cpp

Lines 2870 to 2895 in 49ddf4f

	TEST_F(ClassTests, ExtensibleClassExtendExistingMethodAllowingOverride)
	{
	luabridge::getGlobalNamespace(L)
	.beginClass<ExtensibleBase>("ExtensibleBase", luabridge::extensibleClass | luabridge::allowOverridingMethods)
	.addConstructor<void(*)()>()
	.addFunction("baseClass", &ExtensibleBase::baseClass)
	.addFunction("baseClassConst", &ExtensibleBase::baseClassConst)
	.endClass()
	;
	runLua(R"(
	function ExtensibleBase:baseClass() return 42 + self:super_baseClass() end
	local base = ExtensibleBase(); result = base:baseClass()
	)");
	EXPECT_EQ(43, result<int>());
	runLua(R"(
	function ExtensibleBase:baseClassConst() return 42 + self:super_baseClassConst() end
	local base = ExtensibleBase(); result = base:baseClassConst()
	)");
	EXPECT_EQ(44, result<int>());
	}

I would maybe later enable separate index and newindex metamethods for extensible classes, so to not incur into a performance penalty for classes that are not extensible.

Currently, there are some problems with the super_ methods and inherited classes