Full Fledged Properties

Rob T rob at ucora.com
Wed Dec 19 12:39:08 PST 2012


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


More information about the Digitalmars-d mailing list