On Tue, 29 Jan 2013 09:38:57 -0600, Andrei Alexandrescu
<[email protected]> wrote:
On 1/29/13 6:33 AM, eles wrote:
On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
need to adopt the inferior C# approach.
And there is another problem with the "superior" D approach: a typing
mistake in the name of a property might let you not with one property
that is r/w, but with two properties to which one is r/o and the other
is w/o.
More, those functions might be placed several screens far one from the
other.
I agree this is an issue. I think it's good language design to avoid
"long-distance influence" of one declaration against another.
This is a strong argument for keeping @property for write properties.
Andrei
How so?
The op's argument is against having separate function declarations ala D, and
for a joint getter/setter syntax. i.e.
foo { get; set; }
// vs
int foo() { return 5; }
void fou(int x) {}
Because, as illustrated above, the two function names might accidentally be
different. As the functions, like all overloads, should be 1 code-fold apart,
the actual severity of the bug is the same as accidentally changing the name of
an overloaded function during initial coding or during a refactor. Which is
neither for nor against @property, but advocating new syntax and keywords for
defining properties.
