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