DIP23 draft: Fixing properties redux

[Jonathan M Davis]

On Monday, February 04, 2013 23:56:50 kenji hara wrote:
> 2013/2/4 Andrej Mitrovic <andrej.mitrovich at gmail.com>
> 
> > On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> > > I'm unclear that's a problem.
> > 
> > The problem is you cannot replace a field with a @property function
> > without breaking user-code when you take into account operator
> 
> > overloading. Consider:
> As an essential question, how often occurs rewriting fields to property?
> 
> As far as I thought, such rewriting will cause:
> 1. compile error by type mismatch (if you use &obj.field),
> 2. or, success of compilation *without any semantic breaking* (if you don't
> use &obj.field).
> 
> I think the result is not so harmful.

There's also the issue a variable being able to be passed by ref, which a 
property function can't emulate, which is why it would be quite valuable to be 
able to mark a variable as @property - either to indicate that it's illegal to 
do anything with it that you can't do with a property function or to make it 
so that it lowers to getter and setter property functions and therefore can't 
be used with anything which wouldn't work with a property function.

But if we could guarantee that swapping out variables and property functions 
wouldn't break code, then we could get rid of a _lot_ of property functions 
(since many of them don't do anything other than set and/or return the 
variable that they're wrapping). Because we currently allow stuff which only 
works with a variable or a function, we can't just seamlessly between 
variables and property functions, and it's not going to happen anywhere near 
as often for fear of breaking code. And many more people will simply create 
useless wrapper property functions around variables in case they need to add 
more code to them later (e.g. to validate the argument to the setter). We'd be 
much better off if anything which wasn't legal for both variables and property 
functions was made illegal for property functions and added a way to do the 
same for variables which are supposed to be treated as properties rather than 
explicitly being intended to be public variables like in a POD type.

We could save a lot of boilerplate code if we can simply make it variables and 
property functions guaranteed to be swappable without breaking code.

- Jonathan M Davis