On Wednesday, 19 December 2012 at 06:32:41 UTC, js.mdnq wrote:
So, no one thinks this is a good idea? Any reasons why?
Sorry, but I don't understand your proposal just yet.
Considering the subject "Full Fledged Properties", the current
concept is very limited in terms of what it is able to do with
making a function behave like a variable.
Here's an example of a @property problem I ran into recently
while coding (it is silly because I got stuck on it for a while
but shouldn't have).
I have a @property setter that takes in a struct.
The struct has opAssign overridden so that I can assign to it a
string type.
struct Silly
{
string _s;
void opAssign( string a_val )
{
// maybe do some stuff
_s = a_val;
// maybe do more stuff
}
}
class ReallySilly
{
Silly _Silly;
@property void pSilly( Silly a_silly )
{
// maybe do some stuff.
_Silly = a_silly; // Silly.opSssign is called
// maybe do some more stuff.
}
ref Silly rSilly()
{
return _Silly;
}
}
auto vReallySilly = new ReallySilly;
vReallySilly.pSilly = "string";
// duh, that didn't work! Compiler error.
vReallySilly.rSilly = "string";
// this compiles, but is not what I want.
Of course a @property function is not really a "property", it's
just a function not unlike any other.
So how can I get Silly.opAssign like behavior to propagate to the
setter function without resorting to the ref function?
I have to create another function, overloading on the @property
function.
class ReallySilly
{
...
void Silly pSilly( string a_string )
{
// maybe do some stuff
Silly = a_string;
// maybe do more stuff
}
}
vReallySilly.pSilly = "string"; // Now it works!
However, why bother defining a function with @property in the
first place when there could be multiple setters? Unfortunately D
forbids us to overload on the return type, so there can never be
more than one getter without resorting to regular distinct named
getter functions (I really wish that unnecessary limitation would
be removed).
--rt
