On Saturday, 2 February 2013 at 13:03:49 UTC, Era Scarecrow wrote:
First impression: I don't know why but I don't like it.
It feels like you're doing the following:
1) Declare a struct and immediately instantiate it with the
same name. (Or union, or similar)
2) Only one declaration of this struct can exist, doesn't
count as nested struct.
3) Disable all constructors/postblit/opAssign except as follows
[..]
Memberspaces shouldn't feel like variables at all. They should
feel exactly like C++ namespaces that live inside a struct or a
class. You can't take the address of a namespace or pass it as an
argument. It's just an identifier that can be used to separate
two same names, like std::sort and boost::sort. A nice IDE also
colors memberspaces differently from a variables, etc.
On Saturday, 2 February 2013 at 13:03:49 UTC, Era Scarecrow wrote:
[..]
The only thing it has really done is allow you to force the
use of parenthesis during a call (but only the get, not the
set).
I thought it was an unfortunate side-effect that my proposal
doesn't give us the nice getter syntax:
int n = var.prop;
...but I'm glad you like it (if I understood correctly).
On Saturday, 2 February 2013 at 13:03:49 UTC, Era Scarecrow wrote:
[..]
You're then defining all opBinary/opAssign methods that it
works with which seems like it will end up bloating the code
considerably but not giving back as much as it takes to write
it.
But luckily in D you can write a whole bunch of operators at once
by writing a restricted template operator, like:
void opOpAssign(string op)(int rhs)
if(op == "+" || op == "-" || op == "*" || op == "/")
{
mixin("_value" ~ op ~ "= rhs._value");
}
But you're right in that memberspaces require a more explicit
declaration of a property than most other property
implementations. But those property proposals where you only
specify a getter and a setter, albeit faster to write, they all
suffer from a possible performance issue when the type returned
by getter is non-trivial to copy. I.e.
var.prop += 3;
...has to be done as:
var.prop = var.prop + 3
Also, those other property implementations don't enable you to
call the methods of your property in an encapsulated manner. E.g.
if you property has a non-const set_to_invalid method, you can't
encapsulate further in the struct/class where the property is
defined. I.e:
var.prop.set_to_invalid();
...calls directly PropType.set_to_invalid without the type of
'var' having anything to say about it. That's not good for
encapsulation.
