Possible @property compromise

[Chad Joan]

On 01/29/2013 09:13 PM, H. S. Teoh wrote:
>
> 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
>

I hate to be a bringer of bad news, but I don't think getter/setter 
proxies will ever be an invisible replacement for pointers.

Getter/setter proxies cannot be incremented/decremented, and you can't 
use them in conjunction with the container's pointer to get the offset 
to the field.  Pointers have very specific semantics.

I think it's much easier to just restrict variables from being 
addressable in cases where they will eventually become properties.

I would argue though, that pointers are a getter/setter proxy.  The 
relationship is just not commutative.  What this means is that we can 
treat getter/setter proxies as an algorithmic structure, right alongside 
things like ranges, iterators, containers, etc.  They are the most 
general form of their class: anything that supports assignment and 
retrieval (ex: pointers) is a kind of getter/setter proxy.

I think that we would eventually want a (library-defined) getter/setter 
proxy type.  It will be the only way to defer getting/setting of an 
@property into called code, which is what pointers are currently used 
for in many cases.  Such a type should be possible to construct from 
plain variables, pointers, (hash table + key) pairs, certain functions 
(ex: foo(int getOrSet, void **value)), and anything else you could 
concoct that satisfies the "is a" relationship.

</dream>