This content has been marked as final. Show 9 replies
I agree, those look like IDE generated parameter names, which have no place in a public API (or even a non-public api for that matter, maybe for a simple private method that would do).
Perhaps you are missing something Sands, the Javadoc for the circle constructor you refer to is:
i.e. the exact same naming scheme you are suggesting.
public Circle(double centerX, double centerY, double radius, Paint fill)
On use of the constructor, when my IDE suggests parameter names, it uses the same names you are suggesting.
Perhaps you just don't have the javadoc url configured correctly for your IDE, so it is just generating junk names for parameters?
For Idea, see step 2 of this post => http://stackoverflow.com/questions/13407017/javafx-source-code-not-showing-in-intellij-idea
Other IDEs (Eclipse and NetBeans) should work similarly when properly configured.
If there are other specific issues you have with the API, please raise them in the forums under separate posts or on the jira link you can find in the sticky post - surely not everything is ideal.
Contributions to the codebase can be submitted to: http://openjdk.java.net/projects/openjfx/
Well that explains. So it was just PEBKAC.
I've not missed the javadoc, indeed I state that the 'javadoc says...'.
That only reinforces my argument because the javadoc specifies better names yet the api does not comply.
We should not rely on the IDE to provide us with what the api should look like, the api is wrong and should be amended to match the javadoc; not least because leaving it as it is means that the developer maintaining the Circle class, and others, have to manage the badly named parameters within their code. They will be forced to use the d, d1, d2, etc. and that really makes no sense and harms both readability and maintainability.
I believe the use of parameter names like d, d1, d2, etc. is indefensible.
The source does not use parameter names like d, d1, d2.
I agree that names such as d, d1, d2, etc are indefensible, but that isn't actually our fault (technically) So, lets be clear what is going on (and I've had to rewrite this response far more times, on Christmas Eve, than I should have to do, but I want to be really clear) :-)
The JavaFX Circle class can be seen here: http://hg.openjdk.java.net/openjfx/8/graphics/rt/file/3d2641286b27/javafx-ui-common/src/javafx/scene/shape/Circle.java You should note that it is as you would expect, with proper parameter names.
So, if the Circle class looks like the JavaDoc output (which you also regard as fine), then what is going on? Put simply, IDEs can not always get the information out of the compiled classes, as it may be compiled without the names included. To rectify this, you need to specify either the path to the source code for OpenJFX, or the path to the javadoc file. Refer to http://stackoverflow.com/questions/6303943/why-eclipse-is-generating-argument-names-as-arg0-arg1-arg2-for-methods for more information.
As you should know, our Javadocs are generated from our code, so if you see something named poorly in javadoc, it will be the same in our code, and vice versa.
In short, the JavaFX developers (and I'm one of them) are not being lazy and using bad variable names. We put a lot of effort into naming, to make things as discoverable and understandable as possible. To 'fix' the problem is trivial - but it is between you and your IDE. I mentioned at the beginning that technically we could solve this problem, but that entails building our class files with debug information enabled, which substantially increases the size of our compiled jars, and is therefore not something that is attractive to us (given the ease of the alternative solution).
I hope that helps,
You are correct, my mistake. It seems the ide is responsible for the generated names.
Glad to hear that you do take naming seriously; I apologise for suggesting otherwise.
In a moment of frustration it seemed that it was the api but I stand corrected, I was using a new configuration that was insufficient.
The problem for IDE developers is that we need to point our users to a web URL. If e.g. they have not correctly setup the webproxy in their IDE will fail miserably! I hope this will be solved once all of JavaFX is opensourced with JDK8 and we IDE developers can point our code to the real sources.