On Mon, 27 Jul 2009 13:59:53 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Bill Baxter wrote:
On Mon, Jul 27, 2009 at 7:13 AM, Steven
Schveighoffer<[email protected]> wrote:
On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
<[email protected]> 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
