Sean Kelly wrote:
Don wrote:
Andrei Alexandrescu wrote:
Jacob Carlborg wrote:
[on properties]
What about this:
class Host
{
property acquire release prop
{
T get();
}
}
And then the compiler will automatically created the "acquire" and
"release" methods.
There could also be what I would like to call "property shortcuts"
(ruby calls this attributes) like this:
class Host
{
get acquire release T prop;
get set T prop2;
}
I was hoping I'd shield putative users from having to write verbose
code. Besides, there's one other issue I stumbled upon while working
on porting std.algorithm to ranges.
You can't really pass an entire property to a function. This furthers
the rift between properties and true fields. Consider:
struct A { int x; }
void foo(ref int n) { if (n == 0) n = 1; }
...
A obj;
foo(obj.x);
So when passing obj.x to foo, foo can read and write it no problem.
But if x is a property of A, it all falls apart: obj.x means just
reading the property, not getting the property with all of its get
and set splendor.
I'm starting to wonder if we need some restrictions on fields, in
order to make properties and fields interchangable.
The idea that a field could eventually be completely replaceable with
functions is appealing, but I think it's only possible with a huge
performance hit. One can distinguish between POD fields (for which any
operation is legal) and property fields (which you cannot take the
address of, for example).
Arguably classes should normally not contain public POD fields, only
public property fields. Perhaps this is a useful concept.
I'm hesitant to assert that it should be illegal to take the address of
a public data member, but this is certainly an intriguing idea.
At least, it's something you could do in a lint tool. I think it would
be a useful warning for classes.
It still wouldn't solve Andrei's problem, though, because you still need
public fields of structs to be POD fields, and a struct can still have
properties. Then there are module properties...
The
only other option I can think of would be to make swap a built-in
property of concrete types and expecting the user to call a.swap(b),
though it seems weird that a.swap(b) couldn't be rewritten as swap(a,b)
for any concrete type, regardless of context.
Sean
