Non static functions without userdata

[MeikelLP]

I noticed [LuaObject] generator the code is always generating the following line for non-static methods:

var userData = context.GetArgument<global::MyType>(0);

As you can see here

Sadly I have a lot of legacy scripts (Lua 3?) that do not use the colon syntax x:DoStuff() but rather the dot version x.DoStuff()

This should be fine from my Lua understanding as : is just syntactic sugar for inserting the object as self (ref)

Right now I don't see how I can customize this behavior. My current workaround is to write the objects myself.

[CodeSmile-0000011110110111]

I don't quite understand, could you elaborate what the actual issue is?

You are correct, the : is just syntactic sugar:

x:DoStuff()  -- same as below, but more concise
x.DoStuff(x) -- awkward repetition of 'x'

Because of this I don't see the connection with the C# side of the generator.

Since the method is non-static you have to call DoStuff() on an instance of the type: the x in the above example. So from the Lua perspective the way this binding code is generated is correct, and in fact necessary to pass the x as the first argument. On the surface there seems to be nothing that needs to be changed/customized to accomodate your Lua 3 scripts.

When you use x.DoStuff() on a userdata in Lua 3 it means you are actually calling a static method. Perhaps this DoStuff() on the C#/C++ side wraps to an instance call in your old bindings?

[MeikelLP]

I have a lot (~20mb) of lua scripts. All of them use the "old" way (scripts are from ~2006)

Afaik the : annotation didn't even exist back in the day. Other Lua libraries can handle this (i.e. NLua)

Example:

q.set_counter("count2", 5)

This is the official way: https://www.lua.org/pil/16.html :

The effect of the colon is to add an extra hidden parameter in a method definition and to add an extra argument in a method call. The colon is only a syntactic facility, although a convenient one; there is nothing really new here

[CodeSmile-0000011110110111]

Okay I think I get it. You want this:

Missing Flexibility:
The generator could provide an attribute parameter (e.g., [LuaObject(ImplicitSelf = false)]) that tells it to ignore index 0 for instance retrieval and instead use a pre-bound instance.

However, this doesn't solve the issue entirely. Because the 'q' in your case is nowhere to be found but the exposed method is an instance method:

public class Q
{
    [LuaObject(ImplicitSelf = false)]
    public set_counter(string str, int num) {}
}

How would the generator know where to get the instance of Q from?

You would have to pass it to the global env, and then the LuaObject would need a hint to the attribute:

[LuaObject(ImplicitSelf = false, InstanceKeyInEnvironment = "q")]

Seems like a lot of crud to support 20+ year old scripts. ;)

---

Perhaps the better option for you is to refactor the code on the C# side by making all your methods static, and using whatever way to have a static instance of Q floating about (it's effectively a singleton pattern):

public class Q
{
    static Q _instance = new();

    [LuaObject]
    public static set_counter(string str, int num) 
    {
        _instance.set_counter(str, num);
    }
    public set_counter(string str, int num) 
    {
        // the actual implementation
    }
}

Something tells me it would be easier for you to Roslyn-generate that above static/instance pattern for your C# classes than extending the Lua-CSharp source generator to support a brittle workflow of the past. ;)

Alternatively: utilize the power of AI to generate a regex that will fix the calls to the new syntax.

[MeikelLP]

Sadly those "brittle old" scripts are the heart of the project. If I can't implement them correctly the project is wasted.

Like I said other implementations like NLua doesn't have this issue and I didn't need to implement them statically.

I'd like to know what @akeit0 or @nuskey8 have to say to this issue. If it's against the philosophy of the project - fine I will use NLua. If it's a missing feature I will await an update.

[akeit0]

I have plan to support method access via dot notation.
But first I want to split generator for variations.