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.
A few more reasons:
3. Binary compatibility
4. Read only fields. I quite often want to have read only fields and
basically the only way to that is by using a getter property method. In
D1 I could sometimes avoid this by declaring the instance variable as
const, but that doesn't work in D2
--
/Jacob Carlborg
