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 > <[email protected]> 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.
