On Thu, 23 Jul 2009 15:11:07 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
Michiel Helvensteijn wrote:
Properties. Your syntactic sugar:
int i = c.p; // int i = c.p()
p = i // c.p(i)
They can't do these things:
* No control over their use by class designer: ANY member function
with one
or zero parameters may be called using 'property syntax'. This is not a
good thing.
Why not? Seriously, what is the semantic difference?
It leads to making things look like properties when they are not.
For example, writefln = "hi";
The worst is the assign statement, since there are plenty of legitimate
uses of having a single argument function not actually assign anything.
It can also lead to ambiguities, such as a property that returns a
delegate must be called with double parens:
c.member()();
It has nothing to do with how the compiler looks at it semantically, but
it has everything to do with how the user reads it. I want the compiler
to tell the user "no you can't use that member that way." so I don't get
complaints that my "properties" are badly implemented (and yes, I've had
this happen, see http://www.dsource.org/projects/tango/ticket/1184)
It also forces better coding habits. For example, in C#, when I declare a
property it's:
int x
{
get { return _x; }
set { _x = value; } // value is a context keyword
}
With D properties, x() and x(int value) could be scattered anywhere in the
class.
Notice also, that I can document x as a property, not as it's individual
functions.
* No parameterized properties: c.f(5) = 6; // c.f(5, 6)
Ok.
Ugh, don't do this. You can implement this behavior easily enough. We
already have opIndexAssign.
-Steve
