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:
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!
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
:Output:
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()
asFoo.class.getName()
. (Though I've been doing a lot of work with Jackson XML parsing/generation lately, and having to passFoo.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!
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 ofpublic 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, thenobject.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.