30-Jan-2013 22:05, Zach the Mystic пишет:
On Wednesday, 30 January 2013 at 17:35:25 UTC, Dmitry Olshansky wrote:
Okay, cool. Two questions remain: 1) How hard to implement structs
nested in structs to mimic ones nested in functions?
IMO if property is to be implemented in the library it has to include
the field itself. (And I suspect properties should enjoy compiler
support).
Then something like:
struct A{
Property!(int, filter, getter) prop;
private:
void func()
{
...
prop.raw = xxx; //direct write
prop = yyy; //goes through setter
}
}
where .raw is the field itself and there must be a way to let only
struct itself have access to it. I have one method to get this but I
don't like it - put this in each module:
mixin PropertyForModule!(my_module);
introducing a Property template in this module, with private .raw
accessible thusly only in this module.
Getter is then just any function that maps T => T, with x => x by
default so can be omitted.
Filter is something new but in essence it works like the following
setter:
void setter(T)(ref T val, T newVal)
{
val = filter(newVal); //filter may through
}
It's a bit more restrictive though so feel free to destroy.
Does my suggestion about the compiler detecting a struct with no data
warm you up a bit to properties as structs? If so, there is really very
little need for ANY library support. Strangely, implementing
struct-nested structs with actual data could be a significantly harder
task than implementing them with no data. No extra pointer need be created.
I have one key problem - the hidden pointer detail.
In other words how should it find the instance of the outer struct to to
access it?
struct A{
int a;
struct B{
void foo(){ a = 42; }
}
B b;
}
A a;
a.b.foo(); //how that b is supposed to know it's outer struct without
the hidden pointer?
auto x = a.b;
x.foo();// and now what?
I'll try to summarize the changes required. The first two are necessary.
The third is for aesthetic reasons, but as in the case of lambda
functions that could make a huge difference.
1. Have non-static struct-nested structs be able to refer to their
parent's data. With no-data structs, I suspect this will be easy, and
it's actually the primary intended usage, which makes only the corner
case tricky, where new pointers must be added, etc.
2. Add opGet to the compiler's list of overloads. It is simply opCall
but with parens banned instead of mandated.
3. Enable Highlander structs so that defining a property is as easy as
define a new-style lamba:
struct __fooHidden {}
__fooHidden foo;
simply becomes:
foo struct {}
--
Dmitry Olshansky
