On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu
<[email protected]> wrote:
That's why properties are not
functions.
This post had a negative effect on me: I now think properties are
functions even more than before.
Let me bring you back to the issue at hand:
writefln = "hi";
:)
properties are *implemented* using functions, but both properties and
function usage should be restricted to disallow bizare code.
Another example:
I've brought up this example before, but I'll summarize the issue. I
created a TimeSpan struct for Tango, which represents a span of time. I
had static functions to create time spans, and properties to convert time
spans. For example:
struct TimeSpan
{
static TimeSpan seconds(long n); // returns a TimeSpan representing n
seconds
...
long seconds(); // convert this timespan to seconds
}
So you use it like this:
auto ts = TimeSpan.seconds(5);
assert ts.seconds == 5;
But then I got a bug report one day that this assert fails:
auto ts = TimeSpan.seconds(5);
ts.seconds = 4;
assert(ts.seconds == 4);
What the second line does is create a temporary TimeSpan of 4 seconds, and
throw it away.
What happened here? Why did the compiler compile this code at all? Well,
because I can't tell the compiler "no, that static seconds function is
*not* a property", someone tried to use it as one, and then complained it
didn't work like it should. Would anyone reading the second line of code,
knowing it compiles, *not* think "aha! TimeSpan has a way to set it's
seconds component"?
The "solution" was to rename the static function to fromSeconds, although
this is still valid code:
ts.fromSeconds = 4;
it doesn't look like it means anything (what's this fromSeconds field?).
But WTF? Why do I have to do this kind of shit instead of just telling
the compiler "this is how you use my object. Any other uses are invalid.
End of discussion".
For reference: http://www.dsource.org/projects/tango/ticket/1184
-Steve
