Possible @property compromise

[Adam Wilson]

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.
>
>
> T
>

Indeed, but a better idea would be to fix it, throwing it out seems a bit  
extreme.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/