Using ()s in @property functions

Steven Schveighoffer schveiguy at yahoo.com
Thu Jul 1 04:40:50 PDT 2010


On Wed, 30 Jun 2010 00:33:54 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

>
> I agree with you from a under-the-hood perspective, but I wasn't asking  
> about that. I was asking about the leak in the @property abstraction.  
> Not being able to pass non-ref @properties to functions by ref is a  
> fairly serious (i.e. common) break/leak in the @property abstraction:  
> that @properties should be "virtually indistinguishable from a field".

properties are not fields, they are restricted fields.  That is, you can  
completely control access to a property, but you cannot control access to  
a field.

With a field, you cannot control:

- Who has an address to it
- What the user sets it to
- The action of setting or getting it.

Properties allow control over those things.  The drawback is you cannot  
use it exactly like a field.

I think we would all agree that the main mode of access to a field is:

container.field = x;
x = container.field;

Properties mimic that functionality perfectly, and that is pretty much it.

The one thing I'd like to see for properties is some sort of "property  
delegate."  This could be generated in a struct.  What I don't know is how  
to make it as "virtual" as a real delegate.

Another thing I'd like to see (brought up elsewhere in this thread) is  
some sort of __traits/meta means to get a delegate to a property setter or  
getter, since with required omission of parens, you can no longer get a  
delegate to the property.  This solution could also be amended to solve  
another pet peeve of mine:


struct S
{
     @property void foo(int x);
     @property void foo(string s);
}

S s;
auto d1 = meta.delegateOf(s.foo, int);
auto d2 = meta.delegateOf(s.foo, string);

-Steve


More information about the Digitalmars-d mailing list