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