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.
Incidentally, a simpler way of bridging the divide would have been to
drop property syntax and instead allow public fields to be accessed
using function notation. Setting would be similar to C++ constructors:
int z = obj.x() + 7;
obj.x(6);
How did this hit me in std.algorithm? Replace A with your range of
choice, x with head, and foo with swap. If head is implemented as a
property instead of a ref-returning function or a field, I can't swap
the heads of two ranges!! This limits how ranges can be implemented; I
was hoping to allow head as a property, but it looks like I can't. Same
goes about opIndex. If you define a random-access range, you can't
define opIndex and opIndexAssign. You must define opIndex to return a
reference. That's a bummer.
Yuck.
Andrei
