On Wednesday, 30 January 2013 at 01:59:52 UTC, Robert Jacques
wrote:
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:
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.
He means that in the context where you cannot have write-only
properties. So, you have to have at least the getter. Imposing
@property on the setter means that a getter with the same name is
needed. This lowers the probability of a typo, since a @property
fou() will be caught by the compiler as having no getter
counterpart.
Sure enough, this does not prevent having two getters for foo and
fou properties, then mistakenly writing the setter for fou while
intenfing to write the setter for foo.
