Reddit: why aren't people using D?

Steven Schveighoffer schveiguy at yahoo.com
Mon Jul 27 11:22:57 PDT 2009


On Mon, 27 Jul 2009 13:59:53 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Bill Baxter wrote:
>> On Mon, Jul 27, 2009 at 7:13 AM, Steven
>> Schveighoffer<schveiguy at yahoo.com> wrote:
>>> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
>>> <newshound1 at digitalmars.com> wrote:
>>>
>>>> Ary Borenszweig wrote:
>>>>> Maybe what scares Walter is a whole new syntax for properties.
>>>> It doesn't scare me. It's trivial to add more syntax.
>>>>
>>>> It's just that D is complex enough - there needs to be some very good
>>>> reasons for adding more syntax that has apparently zero semantic  
>>>> information
>>>> that would be different from the usual function syntax.
>>> OK, so you don't like the idea of adding dedicated properties.
>>>
>>> What is *your* solution to forbidding abuses like this:
>>>
>>> writefln = "hi";
>>>
>>> ???
>>>
>>  I think his suggestion was the Java-style approach -- special naming
>> convention for get/set functions:
>>  int opGet_foo() { return foo_; }
>> void opSet_foo(int foo) { foo_ = foo; }
>> private:
>> int foo_;
>>  --bb
>
> For one thing I like that I now get to define empty() for a range and  
> then call it with r.empty. I'd think it would be a small step backward  
> if I had to define get_empty() or something instead.

The "getter" notation that currently exists only has a few minor  
problems.  The most major of those problems is if the return value is a  
callable type, such as a delegate, you can't easily perform the call on  
the returned value.  Being that it isn't very bad for the getter property,  
would it make sense to leave that functionality?  That is:

1. A setter must be defined in the opSet_X(int x) form
2. A getter can be a function with no required arguments, but this getter  
should not return callable types
3. A getter can be defined in the opGet_X() form, and then using X() will  
be the eqivalent of opGet_X()().

There are small implications to leaving the existing getter syntax.   
Namely one can call a function not intended to be a getter in a  
property-like syntax, resulting in less-than-obvious code.  Also, this  
distinction will be very hard to explain to newbies ("how come a getter is  
defined as x(), but a setter has to be opSet_x(...)?).

The more I look at it, the more I like the keyword solution.  I do find  
the C#-like syntax which groups properties together appealing, but I think  
you only absolutely need that if you are going to have context-keywords,  
which I DON'T think we need.  I do find the whole construct of C#  
properties tedious to type.

With a keyword attribute, you could even group your properties together to  
save on typing/ugliness:

property
{
    int x() {}
    void x(int n) {}
    bool empty() {}
}

-Steve



More information about the Digitalmars-d mailing list