@property

[Jacob Carlborg]

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