On 2013-01-31 15:57:12 +0000, "Steven Schveighoffer"
<[email protected]> said:
[...]
Turns out, this translates to:
ts.seconds(5);
and because you can call static methods from an instance (another thing
I don't really like), it made the constructor act like a property! A
completely unintended consequence.
The only viable solution (this was D1), was to rename the functions so
they couldn't be mistaken as properties. So they all became
"fromSeconds" e.g. Yuck!
Could also have used global functions instead of static ones inside of
the class. I still see your point.
At this point, I think it would be a huge step backwards not to solve
(or at least have a yet-to-be implemented solution for) the above
problem. I can live with getters simply being parentheses-less
functions, that isn't so bad (though as an API designer, I'd like to
have full control over that). But using any function as a setter is
crap, and will forever be a wart on D unless we fix it. It will
result in bizarre things like mystery setters that don't exist,
especially with UFCS.
True.
Still, Walter has shown no sign he's willing to accept any solution
that won't work with most of current code. Just look at his syntax
proposal in the thread "take it behind the woodshed and shoot it?" if
you're not convinced. At the same time he has gone to great lengths to
keep things backward compatible even with experimental syntaxes (I'm
thinking of user defined attributes). I seriously doubt changing the
syntax for setters will happen… unless you can make it backward
compatible.
As for keeping the syntax backward compatible, you could for instance
propose an attribute to prevent people from using the setter syntax
when calling a particular function:
@explicit TimeDuration seconds(float);
--
Michel Fortin
[email protected]
http://michelf.ca/
