On Tue, Jan 29, 2013 at 09:44:36PM -0500, Chad Joan wrote: > 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. [...] > > 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,
This is easy to fix in the compiler. > 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. If you write code that is specific to a particular implementation of a field, then it's no surprise that you can't use drop-in abstract replacements. I don't see that as a major issue. > I think it's much easier to just restrict variables from being > addressable in cases where they will eventually become properties. You're right, there is some merit to this idea. > 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 like this line of reasoning. Pointer arithmetic is @unsafe anyway, and in general don't interact well with abstraction, so I don't see lack of pointer support as a major problem. As long as you treat pointers as opaque handles to some value (abstract or otherwise), you can replace them with a 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. [...] I think if we can address the various issues of Rob T's struct-as-variable idea, it might be possible to turn it into a template in Phobos (maybe in std.typecons or something). T -- "I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information
