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;
...
}
