Expand on class conversion support

[JakobOvrum]

Stuff that needs to be supported, if you happen to see this issue, please help me expand on this list.

• Support all translatable operator overloads
• Support entire overload sets, not just the first defined overload
• Fix virtual function behaviour [done]
• Support const and immutable class references
• Properties and public data fields
• Class registration with constructors and static members

[JesseKPhillips]

Functions inside a class marked as const cause a compilation error.

I fixed this by adding cast(void*) on line 128 of conversions/functions.d

[JakobOvrum]

That just makes things worse. Const/immutable class references are not specially handled by the class converter. By casting away const like that you allow const references to be modified by calling non-const methods from Lua. This behaviour is, in some extreme cases, what you want, but the cast shouldn't be in LuaD, it should be done by the host application code.

A proper solution would be to handle const and immutable references by marking them as const or immutable respectively, and by overriding non-const and immutable methods (or only non-const methods when immutable) with an erroring stub function. This is a real issue though and it would be really cool for LuaD to properly handle it, I'll add it to the list.

[JesseKPhillips]

I am not referring to the class reference. This is only a class functions that are const. While there could be an issue with it, I am not seeing one since Lua doesn't care about const and the method is still not going to modify any data when called from Lua (I don't know how you can make it do that).

Or maybe the code I modified effects more than just functions?

[Trass3r]

Have there been problems with adding operator overloading etc or has it just not been done yet?

[JakobOvrum]

I think I have a couple of insignificant local commits towards it, there haven't been any problems. I just haven't been doing a lot of programming lately. I see that LuaD has garnered a bit of interest now, so it's definitively at the top of my list of things to work on.

I'll have a lot of time for programming in about three weeks.

Of course, it'd be awesome if someone would fork LuaD and help out, I'm still paying attention to github so I have time to address pull requests :)

[Trass3r]

So push 'em ;) I think I'll play around with it a bit.

[Trass3r]

btw, the list is still missing property methods and public data fields ;)

[Trass3r]

Oh, and of course real class registration is needed incl. constructors (I'm on it) Could you elaborate on "Fix virtual function behaviour"?

EDIT: just so I don't forget it, what about functions with default argument values?

[JakobOvrum]

I expanded the list.

Default arguments are hard-coded at the call-site, so it would go under supporting overload sets - however, it's not that simple, since I don't think there's a way to check if a parameter has a default value with the current introspection facilities.

Virtual dispatch isn't working correctly right now because the method table is built directly from the first instance of a type pushed. The problem is that it's built directly, even for non-final methods. That means the same method will be used for all instances of that static type, even if they've actually overridden it.

I used to push a unique metatable for every class instance. This solves this particular problem, but introduces a whole bunch of others, and it's really slow compared to the current way.

The proper solution is to add a level of indirection for methods which can be virtual, so it would push a small wrapper method which took the address of the virtual method to be called before calling it, which would properly do the vtable lookup. The only problem is weaving this into the current method-pushing back-end cleanly - I haven't given it much time.

[JakobOvrum]

Virtual functions now work correctly. (6f7f2c301225fc61984af41d0e567b43b30071ff)