DIP26: properties defined

[Michel Fortin]

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.fortin at michelf.ca
http://michelf.ca/