3 ms·

Actually there is something specific: while individual field accessors may make sense in some use cases (ActiveRecord or bidirectional UI mapping), the naming c

Actually there is something specific: while individual field accessors may make sense in some use cases (ActiveRecord or bidirectional UI mapping), the naming convention for them chosen in JavaBeans (“get/setXxx”) is too verbose and doesn’t make sense at all. Compare: 1. a.getFoo().getBar() vs a.foo().bar() or a.foo.bar 2. a.setFoo(1); a.setBoo(“moo”); vs a.foo(1).boo(“moo”); or a.onSomeEvent(1, “moo”); JavaBeans are often used in reflective mapping, but nothing prevents from using simpler convention the same way.

ywei3410 6y ago
That's a fair point. I hadn't considered the names at all; I suppose one could argue that a three letter prefix is the least of Java's verbosity woes.
forgotmypw17 6y ago
In my opinion, the three extra characters are worth it for reducing ambiguity. For example, it's clear to me what setFoo() and getFoo() does, but what about foo()? Does that return the value of foo() or does it run a process called foo()? JavaScript has a different but also unambiguous way of doing it, with a.foo used for properties, and a.foo() used for function. foo() is neither here nor there.
- ivan_gammel 6y ago
  The contexts in which this question would make sense are very rare, so no, it does not worth it. Let me also quote Brian Goetz on this topic: „No discussion involving boilerplate (or any question of Java language evolution, for that matter) can be complete without the subject of field accessors (and properties) coming up. On the one hand, accessors constitute a significant portion of the boilerplate in existing code; on the other hand, the JavaBean-style getter/setter conventions are already badly overused. Mutability may drag with it encapsulation, and encapsulation plus transparency may in turn drag accessors with them, but we should be mindful of the purpose of these accessors; it is not to abstract the representation from the API, but at most to enable rejection of bad values and provide syntactic uniformity of access. (Without rehashing the properties debate, one fundamental objection to automating JavaBean-style field accessors is that it would take what is at best a questionable -- and certainly overused -- API naming convention and burn it into the language. Unlike the core methods like Object.equals(), field accessors do not have any special treatment in the language, and so names of the form getSize() should not either. Also, while equally tedious, writing (and reading) accessor declarations are not nearly as error-prone as equals().)“

ywei3410 6y ago

That's a fair point. I hadn't considered the names at all; I suppose one could argue that a three letter prefix is the least of Java's verbosity woes.

forgotmypw17 6y ago

In my opinion, the three extra characters are worth it for reducing ambiguity. For example, it's clear to me what setFoo() and getFoo() does, but what about foo()? Does that return the value of foo() or does it run a process called foo()? JavaScript has a different but also unambiguous way of doing it, with a.foo used for properties, and a.foo() used for function. foo() is neither here nor there.

ivan_gammel 6y ago
The contexts in which this question would make sense are very rare, so no, it does not worth it. Let me also quote Brian Goetz on this topic: „No discussion involving boilerplate (or any question of Java language evolution, for that matter) can be complete without the subject of field accessors (and properties) coming up. On the one hand, accessors constitute a significant portion of the boilerplate in existing code; on the other hand, the JavaBean-style getter/setter conventions are already badly overused. Mutability may drag with it encapsulation, and encapsulation plus transparency may in turn drag accessors with them, but we should be mindful of the purpose of these accessors; it is not to abstract the representation from the API, but at most to enable rejection of bad values and provide syntactic uniformity of access. (Without rehashing the properties debate, one fundamental objection to automating JavaBean-style field accessors is that it would take what is at best a questionable -- and certainly overused -- API naming convention and burn it into the language. Unlike the core methods like Object.equals(), field accessors do not have any special treatment in the language, and so names of the form getSize() should not either. Also, while equally tedious, writing (and reading) accessor declarations are not nearly as error-prone as equals().)“