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