Possible @property compromise
Zach the Mystic
reachBUTMINUSTHISzach at gOOGLYmail.com
Fri Feb 1 19:14:23 PST 2013
On Friday, 1 February 2013 at 21:33:31 UTC, Rob T wrote:
> It's one thing to implement a struct, and another thing to
> implement nested structs that can refer to the host instance. I
> know some people want nested structs that can work in that way,
> but implementation is problematic because when the host struct
> is moved, then the nested struct has to move along with it and
> this one reason why we don't have them.
I am not proposing this and I don't think it's actually
necessary. My nested struct is just a tried-and-true struct. So
what's the difference? How does it still succeed? Not because it
contains any special data or hidden pointers unto itself. Rather,
because its *functions* are written to *accept hidden pointers*.
That way they can operate on whatever instance of their parent's
type gets sent to them. They could be optimized, in theory, to
only accept pointers to instances they actually worked on. For
example, if a nested member function did nothing but set an
integer defined in a struct three nests up, it only need take an
instance of that struct, but that's an advanced optimization, not
necessary for a basic implementation which would simply pass
three pointers to every three-deep nested struct member function.
If you want an example, just ask.
More information about the Digitalmars-d
mailing list