Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

better constructors #1

Open
electronstudio opened this issue Apr 3, 2020 · 7 comments
Open

better constructors #1

electronstudio opened this issue Apr 3, 2020 · 7 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@electronstudio
Copy link
Owner

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 electronstudio added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed and removed good first issue Good for newcomers labels Apr 3, 2020
@electronstudio
Copy link
Owner Author

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

@electronstudio
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

#62

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant