On 01/29/2013 06:26 AM, eles wrote:
On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
to the one used for functions. That way, you can avoid verbosity and
the need to use implicit parameters
What do you eran from that? Sparing "value" as a reusable identifier?
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"?
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.
IIRC, C# goes like this:
property int foo
{
get
{
return m_foo;
}
set
{
m_foo = value;
}
}
C# properties have a couple disadvantages:
- They introduce an extra nesting level.
- There is a possible nonsense error if someone places code outside of
the get/set but inside the property scope.
- You don't get to determine how the setter value is passed. ref? auto
ref? const?
- They use 4 keywords, whereas we can get away with 2 probably.
- Things get uglier when you add D's function pure and const annotations
to it.
I think there are another disadvantage or two that Andrei mentioned
before in a property discussion a couple years ago. He fairly well
convinced me that C#'s property syntax isn't the right thing for D.
Semantically, they accomplish the same thing as D's properties: they get
lowered into two methods, one getter and one setter. There has to be
/some/ way to attach executable code to a symbol for this properties
concept to work at all.
