@property

[Jonathan M Davis]

On Saturday, August 04, 2012 21:11:47 Jacob Carlborg wrote:
> On 2012-08-04 21:08, Jacob Carlborg wrote:
> > I think that you should always be able to replace a variable with a
> > property. The other way around I'm not so sure. The problem is with
> > methods in classes. Since a method will be virtual by default you can't
> > just replace a property with a variable. That could potentially break
> > subclasses that override the property.
> 
> I wouldn't actually mind a way to do this, perhaps something like this:
> 
> class Foo
> {
>      @property int bar:
> }
> 
> Would be the same as:
> 
> class Foo
> {
>      private int bar_:
>      @property int bar () { return bar_; }
>      @property int bar (int value) { return bar_ = value; }
> }1

That would be kind of cool, though I would have suggested that putting 
@property on a variable would make it so that you couldn't do anything with it 
that you couldn't do with a property (e.g. taking the address of a variable 
will break when it's switched to a property, and @property on the variable 
could prevent that). But maybe your proposal is better - though I'm not sure 
how much I'd end up using it, because if you wanted to actually use the member 
variable, you'd get into naming issues. You proposed bar_ here, but I'd have 
gone with _bar, whereas some would have suggested m_bar, and regardless, 
there's no way to indicate the name with this syntax, so you'd have to either 
just know how the compiler names such variables or statically disallow using 
the property through anything other than the proprty functions. And if all the 
property does is get and set with _nothing_ else, then how is that any better 
than a public member variable, assuming that switching between a variable and 
a property is seemless like it's supposed to be? So, I think that I'd still 
prefer the approach of making it so that marking variables @property makes it 
so that you can only use them in ways that you can use a property function, 
since it gives you the same result without needing to actually create any 
functions or come up with naming schemes for implicit member variables or 
whatnot.

- Jonathan M Davis