DIP23 draft: Fixing properties redux

[Chad Joan]

On 02/04/2013 11:18 PM, Andrei Alexandrescu wrote:
> On 2/4/13 10:30 PM, Chad Joan wrote:
>> On 02/04/2013 05:28 PM, Andrei Alexandrescu wrote:
>>> On 2/4/13 2:04 PM, Jonathan M Davis wrote:
>>>> 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.
>>>
>>> I think this is quite powerful. The way we can do this is by making
>>> properties emulate a subset of actual variables.
>>>
>>> Andrei
>>
>> I agree with Jonathan.
>>
>> Please do not make them a subset. Make them as identical as possible.
>> The subset thing makes them no longer "swappable". Allow variables to be
>> marked with @property to limit them to operations that @property
>> functions can do, and make sure @property functions are limited to what
>> @property variables can do (ex: no address-of!). With that in hand,
>> they'll be very swappable.
>
> The purpose is to replace members with properties, not to change one's
> mind back and forth. There will be no marking of variables with
> @property as that can be easily achieved by actually making them
> properties.
>
> Andrei

Why not allow one to change their mind back and forth?

That would be far more useful from a design perspective.  With what 
you're proposing, there is no migration path for variables.  They are 
not swappable at all.  Once someone takes the address of your "public 
int foo;" it will no longer be possible to turn it into a property 
without breaking API.

Going even further, suppose we allow @property variables and also allow 
address-of on @property functions only (a subset relationship!).  Now it 
is possible to make a "public @property int foo;" that can be migrated 
to a full-fledged property later without some god-awful boilerplate. 
However, the developer will hesitate to make such a change: converting 
@property variables to @property functions is a liability.  Once you 
convert, you can't convert back without breaking API.  At that point the 
hypothetical developer wonders: "why am I using @property variables in 
the first place?  I can't migrate them because of the liability, which 
makes them no more useful than public variables that break 
encapsulation."  At that point the whole concept goes out the window and 
we're back in Java writing drivel like this:

class XYZ
{
   int m_foo;

   int getFoo()
   {
     return m_foo;
   }

   void setFoo(int val)
   {
     m_foo = val;
   }

   ...
}

I'm arguing the point because I'd much rather write this:

class XYZ
{
   @property int foo;
   ...
}