Creating Clearer Method Names & Concepts

[Knut Arne Vedaa]

Binding in JavaFX is certainly another source of confusion. You have 
"binding" and you have "Binding":

A Property<T> has a method "bind", of which the doc says: "Create a 
unidirection binding for this Property."

While there is also the interface Binding<T>, of which the doc says: "A 
Binding calculates a value that depends on one or more sources."

The fact that these concepts are related, but not the same, but still 
share the same name, makes it more difficult for newcomers to get a 
grasp of the concepts in the API. At least so it was for me.

Probably too late to change, though. But perhaps documentation could be 
more clear about it.

In general, I think naming is a compromise between succintness and 
uniqueness. In order to guarantee uniqueness you would need to use long 
descriptive names (which probably are seen often enough in Java 
frameworks as it is). Shorter ones look better, but clash more easily. 
Sometimes it might even be better to use names that are not perhaps 100% 
logical when seen in isolation.


Knut Arne Vedaa


On 02.11.2012 21:24, Richard Bair wrote:
>> I know it's probably in people's noise level at this point, but the
>> semantics behind the names of things often make all the difference when
>> you're trying to figure things out.
>
> I agree, names actually are one of the hardest aspects of API design, particularly because so many names are reused in computer science (like binding!) for so many different things. I do not anticipate that when we do validation that the bindings themselves will expose this new validation concept (I imagine the Controls themselves will do so), but who knows.
>