Possible @property compromise

[H. S. Teoh]

On Tue, Jan 29, 2013 at 06:05:15PM -0800, Adam Wilson wrote:
> On Tue, 29 Jan 2013 17:32:20 -0800, H. S. Teoh
> <hsteoh at quickfur.ath.cx> wrote:
> 
> >On Wed, Jan 30, 2013 at 02:23:26AM +0100, Jonathan M Davis wrote:
> >>On Tuesday, January 29, 2013 17:06:32 H. S. Teoh wrote:
> >>> Why do you have to mark naked variables as @property? Isn't that
> >>> redundant?
> >>
> >>In order to restrict what you can do with it to the subset of
> >>operations that you can do with a property function. In particular,
> >>taking its address would need to be illegal, as that won't work with
> >>a property function (or if it did, it would return a different
> >>type).
> >
> >I see.
> >
> >
> >>It would be impossible to replace a normal variable with a property
> >>function without risking breaking code, because there are operations
> >>that you can normally do on a variable that couldn't possibly be
> >>implemented with a function (such as taking its address). But if you
> >>mark it to restrict what it can do, then you could swap it out with
> >>a function later without the risk of breaking code (which is one of
> >>the main reasons for having properties in the first place).
> >>@property doesn't currently do this, but it could, and if we don't
> >>have something like that, then it'll never be safe to swap variables
> >>and property functions.
> >[...]
> >
> >If this is the case, then I would have to say that @property is
> >fundamentally broken. The whole point of @property is to make
> >functions behave like variables, but if this "variable emulation"
> >isn't even complete, then it defeats the purpose of having it in the
> >first place.
[...]
> 
> Indeed, but a better idea would be to fix it, throwing it out seems
> a bit extreme.
[...]

I'm not for throwing it out, actually. :) Just pointing out some
problematic aspects of it.

One way to solve the '&' problem is to have the compiler lower that into
a delegate that gives access to the setter/getter for that field. Then
@property *would* indeed be a drop-in replacement for member variables.


T

-- 
In theory, there is no difference between theory and practice.