OK, this is getting ridiculous. It’s been, what, 25 years since Java started and we still haven’t fixed one of the single biggest pain-points for the language—properties. I mean, just look at this mess:
|
1 2 3 4 5 6 7 8 9 10 11 |
class Foo { private String name_; public String getName() { return name_; } public void setName(final String name) { name_ = name; } } |
The amount of boilerplate is huge and that’s without considering other boilerplate methods like equals():
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
public class Foo { private String name_; public String getName() { return name_; } public void setName(final String name) { name_ = name; } public boolean equals(final Object obj) { if (obj instanceof Foo) { Foo rhs = (Foo)obj; if (rhs.getName().equals(rhs.getName()) { //Ignore nulls for simplicity return true; } } return false; } public int hashCode() { int result = 17; result = (result * 37) + getName() == null ? 0 : getName().hashCode(); return result; } //Possible compareTo(), toString(), and more. } |
Ugh, I hate typing all of that. If the object is a bean/POJO then we can use generators to help write some of the code at the expense of some weird code: strange inheritance, abstract objects, annotations, etc.
Now with properties and some compiler magic we could have the same behavior that looks more like this:
|
1 2 3 |
public class Foo { public property String name; } |
And this would internally generate the second example above. If you don’t like adding new keywords we could do it almost as elegantly with annotations:
|
1 2 3 |
public class Foo { @property public String name; } |
This could easily be extended to support read-only properties as well as overriding the getter/setter. Overriding the setter is needed to validate the value.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public class Foo { public Foo() { name = “”; } @NotNull public property String name { //@NotNull prevents setting to null set { if (value.length() > 100) { throw new IllegalArgumentException(); } } } } |
This would internally generate the equivalent of this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public class Foo { private String name_; //Actually an untypeable name public Foo() { name_ = “”; assert(name_ != null); } @NotNull public String getName() { return name_; } public void setName(@NotNull final String value) { if (value.length() > 100) { throw new IllegalArgumentException(); } name_ = value; } //plus equals and hashCode } |
Note the assert in the constructor in the generated version. This was added by the @NotNull annotation. If the code generator can guarantee that name is set before the end of the constructor the it can elide the assert().
Anyway, there is a lot more that can be done. A property could be marked as part of the object’s ordering and then it would be added to a generated compareTo() method. The basic idea is to remove the boilerplate and to force consistency in code between programmers.