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.
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 finalconstants) 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.somethingcan 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.