better constructors

[electronstudio]

Javacpp creates noarg constructors and expects you use the fluent methods to initialize, e.g.:
new Vector3().x(16).y(8).z(16)

It would be nicer for Java programmers if we could make a constructor so you could do:
new Vector3(16,8,16)

I know how to do this as a helper method, but I don't know how to insert it as a constructor into the generated Raylib.java source.

[electronstudio]

I have created Jaylib.Vector3 which inherits from Raylib.Vector3 but has additional constructors. I suggest creating similiar subclasses of the autogenerated classes.

[electronstudio]

Using subclasses can get confusing, because the library functions dont return the subclasses. Might be better to create helper functions and get rid of the subclasses?

[electronstudio]

Alternative would be to create subclasses for everything, and create wrapper around the library functions that use the subclasses. Result would be ideal but it's work that would have to be updated every time Raylib is updated, and the goal of this project is to automate things so there is no work.

[electronstudio]

JavaCPP does not generate constructors. The recommended JavaCPP way is like this:

 var vec = new Vector3().x(1).y(2).z(3);

I made some sub classes in Jaylib.java. To use those:

import com.raylib.Jaylib.Vector3;
...
var vec = new Vector3(1, 2, 3);

I made some constructor functions in Jaylib.java. To use those:

import static com.raylib.Jaylib.Vector3;

var vec = Vector3(1, 2, 3);

I'm undecided which of these methods is cleanest but I recommend the first because it's autogenerated by JavaCPP.

[electronstudio]

I'm thinking the helpers are not actually a good idea, because they make it easy to think you're dealing with Java objects, when actually these are chunks of memory allocated on the native heap. The GC behaviour is different and the JVM won't be able to do boxing, escape analyse, etc, optimizations on them. The unusual syntax helps to remind me of that.

[electronstudio]

having the Jaylib.* subclasses causes a lot of confusion for users of the library.

The original reason they were created was that people didn’t like the JavaCPP fluent syntax and wanted traditional constructor methods. So I made those, but they couldn’t go in the auto generated Raylib.* classes, so they went in subclasses in Jaylib.*. I figured that any time Raylib required a struct as an argument, the user could supply a subclass if he preferred and no other changes would be required.

However if people are finding the need to convert back and forth between the Jaylib.* subclasses and and the Raylib.* classes then this must have been the wrong approach.

What I’m thinking now is we should eliminate the Jaylib.* stuff completely and instead of having constructors have methods like createCamera() that return a Raylib.Camera.

[electronstudio]

#62