Why do we need 3 Vector3 types?

[Shadowraix]

Firstly, I am only speaking from a Lua developer point of view. I don't know if there's any technical limitations to what is being suggested in the rest of this post.

So, 3 Vector3 types are exposed in the Lua API. Vector3i, Vector3f, and Vector3d
These each represent a Vector3 with different number data types. As far as being exposed to the Lua API, I think this isn't a good choice.

On the programmer side of Lua, you can see that messing with number data types really isn't a thing in Lua. This is because Lua has always interpreted these data types for us. The design allows us to not care too much about it. Having 3 Vector3 classes that accept different data types kind of defeats the original design.

Ideally, on a plugin developers perspective, having a single Vector3 class and then the data types being interpreted elsewhere would be a more clean and better design choice if this is possible. This increases simplicity to the plugin developer and should ideally still keep the optimization of having the proper data types.

[xoft]

The three types are used in the C++ code, and it would be quite difficult to merge them on the Lua side, simply because any exported function that takes or returns a Vector3<T> would need to be exported manually.

[Shadowraix]

The three types are used in the C++ code, and it would be quite difficult to merge them on the Lua side, simply because any exported function that takes or returns a Vector3<T> would need to be exported manually.

So basically a merged Vector3 function isn't practical due to issues on the C++ side of things?

This kind of seems like a big issue if you can't control a separation between the C++ API and the Lua API

[xoft]

Most of the Lua API is generated automatically from the C++ header files, so it's generated to match the vector type used. If we decided to merge the vector classes to a single one, we'd need to manually export maybe a hundred functions, maybe even more, which is too much of a burden. I think the cost-to-gain ratio is too high for this.

[Shadowraix]

Most of the Lua API is generated automatically from the C++ header files, so it's generated to match the vector type used. If we decided to merge the vector classes to a single one, we'd need to manually export maybe a hundred functions, maybe even more, which is too much of a burden. I think the cost-to-gain ratio is too high for this.

I volunteer as tribute. (Once I know C++) Yes, I am completely serious.

[xoft]

It's not only about writing the bindings, it's about maintaining them afterwards as well. It's much better to have automated bindings generated than having to update them manually.

[Shadowraix]

It's not only about writing the bindings, it's about maintaining them afterwards as well. It's much better to have automated bindings generated than having to update them manually.

This just worries me because I mean the API for Lua developers is still very important. Having a clean and simple API could attract more developers. I showed my friend MCServer who is a big-time web programmer and uses Lua for game programming here and there. He was turned away because he found the API to be in a messy state. I'm not talking about the Vector3 thing in particular. It just seems like the API could use a lot of work to make it easier and more simple to use than it already is.

[SamJBarney]

It's not only about writing the bindings, it's about maintaining them afterwards as well. It's much better to have automated bindings generated than having to update them manually.

It would be even better if we didn't have to generate bindings or write them ourselves. I'm working on something that would solve that for us, but it will be a few months before it will be useable.

[worktycho]

How? A replacement for tolua?

[SamJBarney]

It's called the Unified Programming Engine (UPE for short). It's kinda hard to fully describe without a large, large post, but it is being developed to allow people to write code in whatever language they want, and have it work seamlessly with any other language.
It could definitely replace tolua, and remove all of that binding code.

If you want, I could start a new thread that explains it all in detail, along with the pros and cons that I can see.