@property
Jacob Carlborg
doob at me.com
Sun Aug 5 05:09:39 PDT 2012
On 2012-08-04 21:28, Jonathan M Davis wrote:
> 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.
I see two reasons:
1. The generated methods will be virtual
2. I'm thinking that it would be possible to override either the getter
or setter. Meaning you would get one for free
class Foo
{
@property int bar:
@property int bar (int value)
{
validate(value);
return bar_ = value;
}
}
In the above code, only a getter will be generated.
About the name of generate instance variable, we could add syntax making
it possible to change the name:
class Foo
{
@property(name=m_bar) int bar:
}
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list