DEV Community

Discussion on: Modernizing Java - A language feature wish list (Part 1)

Collapse
 
craser profile image
Chris Raser • Edited

I liked reading this, thanks for posting! I whole-heartedly support features that help reduce the clutter of null checks.

But I've worked with languages that have the "syntactic sugar" for getters and setters, and I found the experience unpleasant. Maybe it's years (and years...) of ingrained habit, but the difference between a variable assignment and a function call is important, especially when reading through code and debugging.

But here's the real hitch as to why it's problematic to have the compiler "figure out" what you mean when you type, foo.name:

public class Fizz
{
    public String name = "fizz";

    public String getName() {
        return name;
    }
}

public class Buzz extends Fizz
{
    public String name = "buzz";

    public String getName() {
        return name;
    }
}

public class Main
{
    static public void main(String[] args) {
        Fizz fizz = new Buzz();
        System.out.println("fizz.name     : " + fizz.name);
        System.out.println("fizz.getName(): " + fizz.getName());
    }
}

Output:

fizz.name     : fizz
fizz.getName(): buzz

That's because Java dispatches to member fields based on the reference type, (Fizz in this example), but dispatches to methods based on the object type (Buzz).

Having the compiler "figure out" what you mean requires accounting for this, which requires that developers memorize yet more arcane rules.

I'm all for simplicity and readability, but I think in this case it's an illusion. Typing & reading getFoo() aren't the hard part of coding. Understanding what the code does is the hard part. And I think adding this syntactic sugar make the hard part marginally harder in order to make the easy part easier. I just don't think that's a good trade-off.

I have similar thoughts on letting the compiler resolve Foo.getName() as Foo.class.getName(). (Though I've been doing a lot of work with Jackson XML parsing/generation lately, and having to pass Foo.class as a type token is... unattractive.)

Thanks for posting this. I like mulling new language features, and I'm now curious to check out Ceylon. Thanks for the pointer!

Collapse
 
martinhaeusler profile image
Martin Häusler

Thanks for reading! I'm glad you enjoyed it. The next part will be online this week or next week (I hope, pretty busy over here).

Regarding your comment on the getter/setter syntax. To be honest, the problem that I see in your example code is not so much the fact that the programmer has to be aware that they are calling a method. I think the problem lies within the fact that there is something other than a method that can be adressed with object.something. I've seen, written and reviewed my fair share of Java code in particular and so far, nobody could ever provide me with a reasonable example why public member variables (with the sole exception of public static final constants) are necessary. They break encapsulation. Once exposed in public API, a field can never be replaced with a getter, whereas a method body can be modified freely as long as the contract isn't violated. Public members always means exposing more internal logic than necessary. To be honest, I consider public non-constant fields deprecated and even harmful. If you only ever expose methods, then object.something can only have one meaning: it's a getter (or setter). No arcane magic here to keep in mind. Perhaps somebody can prove me wrong here, but I've yet to see a real use case for public non-constant fields, other than "I'm too lazy to write a getter/setter pair for that."

Ceylon has cool concepts, the syntax is quite hard to handle if you ask me. As far as I know, language development for Ceylon has pretty much died, unfortunately. Still, the features and core ideas are great.