What do you eran from that? Sparing "value" as a reusable
identifier?
Not using a magic identifier, which makes the code clearer.
You define a getter at the top of the class, then finding a
setter three screens lower and you finnaly learn that the
property is not that "read-only"?
Nothing is stopping you from keeping the getter and setter
together. It also seems to me that this is something people would
usually do, as you usually write one of those right before you
write the other, and later inserting some other definition
between them just feels wrong. How many times have you
encountered this problem?
I think the first step into better property
definition/implementation/comprehension would be exactly that:
to force the code of the getter and the code of the setter to
stick together.
Yes, exactly at the user of a property I was thinking. That
user is also a programmer, but he does not do the
implementation of the property, just using it.
The confusion does not lie with that user, but it was sparked
when the implementation decision was made, in the very heads of
those who started implementing properties as
just-another-function.
This confusion propagates from the implementors to the user, as
the (usage) syntax issues are issues for the user.
It also does not help that, for the time being, the users of
properties are also the implementors of properties. There is
not much objectivity in this case.
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 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.
