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>
