Possible @property compromise

[H. S. Teoh]

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