On Tuesday, 29 January 2013 at 12:18:56 UTC, jerro wrote:
What do you eran from that? Sparing "value" as a reusable
identifier?
Not using a magic identifier, which makes the code clearer.
Yes. What about removing $ in array context? That makes it a very
magic identifier.
OK: use "$" instead of "value". It is magic already.
Nothing is stopping you from keeping the getter and setter
together.
The problem is that nobody enforces you. Nobody is stopping you
from writing corect code, I can swear that. Still, bugs exist.
And in your code, too.
So you are assuming that having a special syntax for defining
properties has some psychological effect on programmers that
results in proper usage of properties, and that the lack of
such syntax in D is the main reason for improper property usage.
I think it will make things clearer for them: a lot of debate was
needed just to make clear that UFCS/optional_parens and @property
are orthogonal issues. Do you think that confusion in the
beginning had nothing to do with the F meaning... FUNCTION?
I disagree. I think that the main reason @property is currently
overused in D is that people were under the impression that
paren-less calls will only be supported for @property
functions in the future. So if people wanted some of their
functions to be callable without parens (and some people do
want that), they actually had an incentive to make them
@property, even if they weren't logically properties.
You see: optional parens mean function, @property means property.
The confusion that you spot is exactly the confusion that is
rooted into that mix of properties and functions.
