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