Reddit: why aren't people using D?
Steven Schveighoffer
schveiguy at yahoo.com
Thu Jul 23 12:38:06 PDT 2009
On Thu, 23 Jul 2009 15:11:07 -0400, Walter Bright
<newshound1 at digitalmars.com> wrote:
> Michiel Helvensteijn wrote:
>> Properties. Your syntactic sugar:
>> int i = c.p; // int i = c.p()
>> p = i // c.p(i)
>> They can't do these things:
>> * No control over their use by class designer: ANY member function
>> with one
>> or zero parameters may be called using 'property syntax'. This is not a
>> good thing.
>
> Why not? Seriously, what is the semantic difference?
It leads to making things look like properties when they are not.
For example, writefln = "hi";
The worst is the assign statement, since there are plenty of legitimate
uses of having a single argument function not actually assign anything.
It can also lead to ambiguities, such as a property that returns a
delegate must be called with double parens:
c.member()();
It has nothing to do with how the compiler looks at it semantically, but
it has everything to do with how the user reads it. I want the compiler
to tell the user "no you can't use that member that way." so I don't get
complaints that my "properties" are badly implemented (and yes, I've had
this happen, see http://www.dsource.org/projects/tango/ticket/1184)
It also forces better coding habits. For example, in C#, when I declare a
property it's:
int x
{
get { return _x; }
set { _x = value; } // value is a context keyword
}
With D properties, x() and x(int value) could be scattered anywhere in the
class.
Notice also, that I can document x as a property, not as it's individual
functions.
>> * No parameterized properties: c.f(5) = 6; // c.f(5, 6)
>
> Ok.
Ugh, don't do this. You can implement this behavior easily enough. We
already have opIndexAssign.
-Steve
More information about the Digitalmars-d
mailing list