I wrote:
I believe both module-level properties and UFCS properties to be
desirable. So is the idea put forward in DIP26 that reduces boilerplate
code. The question is how do we put all that together.
Andrei just made me realize that I overlooked this part of DIP26 which
actually solve the most of the problem of UFCS (see the Upgrade Path
section):
Generic code won't break: It can use optional parentheses, but does not
have to. Calling a delegate returned by a function/property function is
always:
front()();
So whether a getter is a property or not does not change anything at
the call site, meaning that UFCS getters (or any getter with no
associated setter for that matter) don't need to be properties. What
remains is that you can't write UFCS *setters*. But UFCS setters are
definitely less common, and if that's really important I guess it could
be solved though separate means.
So in short, this proposal is that @property does only two things when
applied to a function: it enables the setter syntax and it changes the
overload rules.
I like the conclusion:
So this DIP is exactly the opposite approach of solving the property
problem: Don't make them look more like fields, make public fields more
look like functions.
Don't try to make functions look like fields, this can not work. Just
do it the other way round: Don't ever make a field public, but use
properties, as every OOP book tells you anyway. And all problems are
solved, as far as I can see.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/
