On Thu, 31 Jan 2013 19:59:46 -0500, Zach the Mystic
<[email protected]> wrote:
I think my suggestion goes far beyond what you suspect. It goes way
beyond mere getting and setting of variables. Here is basically how you
implement a basic int as a property, assuming my new syntax and language
adjustments. You need: 1) a struct to have the property in, which is
just a normal struct. 2) An actual integer which will be indirectly
accessed by using the properties. Let's call it "_n" and the property
"n". 3) a struct to hold all of the property functions which access _n.
THIS STRUCT CONTAINS NO DATA OF ITS OWN. 4) A bunch of methods
implementing all the operators you want. For int, that's quite a lot, so
I'll shorten it to a getter, a setter, and an adder. I'll even leave out
opGet and use an alias to what might as well be opGet. I'll give the
adder a little personality because what's the point of properties if
they don't do something different from a basic type?
struct myStruct
{
int _n;
n struct
{
int __mightAsWellBeOpGet() { return _n; }
alias __mightAsWellBeOpGet this;
int opAssign(int newN) { _n = newN; return _n; }
int opBinary(string op) (int rhs)
{
static if (op == "+")
{
writeln("You sure are adding a funky int, my friend...");
return _n + rhs;
}
else static assert(0, "Operator "~op~" not implemented");
}
}
}
This is not some kind of special property implementation. n is a struct.
It has no data and therefore is a very peculiar kind of struct. A struct
with no data needs only one instance, ever. Copying it is pointless.
Taking its address is pointless. Creating a new instance is pointless.
Passing it by ref is pointless. All operations which require more than
one instance are pointless, which is why it doesn't need a separately
defined type. The type and the instance can therefore use the same name,
n in this case.
No, the struct must have data. If it doesn't, how does it get back to the
owner type? In other words, your n struct must have a pointer to the
myStruct instance it intends to modify _n on.
Unless, of course, you pass the pointer to myStruct as the 'this'
reference. But then, this isn't a normal struct, and I'm really failing
to see why we have to make this a struct at all.
Note that n uses the new rule which allows it access to its parent's
scope, the same way it would in a nested function. The only pointer it
needs is the same pointer used for myStruct, since myStruct actually
stores some data.
FYI, nested structs in functions (the ones you want to use as a model)
have an extra hidden reference pointer back to the stack frame data. That
is how they can access the local variables of the function.
This proposal looks way too complicated. I don't see how it's a win over
the current state of affairs, or even the @property implementation we
expected to get but didn't. You need to solve the "owner pointer" problem
before it's even viable.
-Steve
