On Friday, 1 February 2013 at 17:43:54 UTC, Zach the Mystic wrote:
[...]
Syntactically, we can allow the property to contain its own
data internally, but the data will really belong to the hosted
structure (class, struct, or module level).
I don't like this because structs don't already work that way.
All structs can work in exactly the same way. I'm pretty sure
there's no need to treat these specially... except under the
hood, where compiler optimizes away the unnecessary pointers in
the case of data-free structs.
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 proposing that we avoid the nesting problem by storing all
enclosed data outside in the host instance, but this means that
the concept is more like a namespace than a real struct, i.e., it
is not movable and cannot be accessed in isolation from the host.
Nothing really new needs to be implemented because there's no
special need for storing a "this" pointer, and functions get
called in the same way as before. The "this" is the host
pointer. We can still refer to an inner and an outter this
pointer, but that's really an alias for either the hosts
"this" (outter) or the property namespace (inner), both use
the same this pointer.
The problem with overriding "this" is if you later add data to
the struct, it will break any code that already uses "this".
"outer" doesn't have this problem at all, and is arguably
clearer. Therefore, I think "this" should simply be a
compile-time error with a data-free struct.
The idea here is that we have a property implementation that
behaves like a namespace but also has some of the features that
structs have. We should not call this thing a struct because it
is not a true struct, it's something else entirely, not a
namespace and not a struct, but it shares some features with both.
If you add data to the namespace-struct, the data is not stored
inside the namespace, it only appears that way, it's instead
stored with the hosting object instance, be it struct, class, or
module, so data storage is like a namespace.
The "inner" simply refers to the "this" pointer of the host
instance, but limited to the data that was declared inside the
namespace, the outter pointer refers to the "this" of the host
instance as well, but limited to the hosts data instance only.
For modules I don't think there's a this pointer, but that's an
implementation detail that can be resolved.
No, the struct-property will not behave exactly like a
variable, and I think that idea is a dead end anyway because
it's far too complicated to implement and has questionable
value. I agree with Walter, it's needs to be put down so we
can move on and come up with a better idea that can work and
is really useful.
I don't know, Rob T... Walter's recent article on half-floats
shows that you can get a struct instance to look pretty darn
close to a variable. Is there anything a variable can do that
half-floats can't do? Because if not, we're in the money, dude.
This does exactly the same thing, just with data stored outside
the struct itself.
The Half-Float implementation is not a nested structure, and
trying to implement nested structs is where all of the major
difficulties come from.
I may intuitively feel this is a great idea, but we will need
a few compelling use cases that solve real world problems to
make a case for it.
--rt
Yes, but on the other hand, if you provide all the
functionality previously requested, plus a whole lot more, a
compelling use case becomes a lot less important. Undiscovered
country.
I think we can easily replace @property already with the
namespace proposal, however it will not be the full variable
emulation that some people had wanted.
I don't think full variable emulation can be done anyway and I've
seen admissions that it cannot be done by some of the people who
want to see full variable emulation. What we can get however is a
much better implementation of the property concept through a new
gadget that works like a namepsace with some of the nice features
seen with structs. I doubt we'll ever see true nested structs
that can reference data in a host structs instance and contain
it's own data because it introduces a pointer sync problem when
the structs are moved around.
At this stage in the discussion, I believe that Steven
Schveighoffer is correct that we'll get more traction if we drop
the nest struct idea and focus instead on implementing a D
version of the C++ namespace, with the improvements that allows
things like properties to be implemented.
If we can show that there are other uses for the idea, then it
adds a lot more credibility to the idea because as it stands, we
can get properties right now, but they suck (IMHO anyway). If the
proposal is only a marginal improvement over what we have now,
then it may not be seen as worth implementing.
--rt
