Re: Using memberspaces for a property-like syntax and more

[Era Scarecrow]

On Saturday, 2 February 2013 at 23:23:37 UTC, TommiT wrote:
You say "there's no real benefit". I say "there's the benefit 
of being able to add another layer of encapsulation when it's 
needed". Here's what I mean by that:

The lack of encapsulation with @property attribute:

struct T
{
    private int _value;

    void add_twice(int v)
    {
        _value += 2 * v;
    }
}

struct S
{
    private T _t;
    private int _sum_of_squares; // Can't update this

    @property ref T prop()
    {
        return _t;
    }
}

void main()
{
    S s;
    s.prop.add_twice(); // *Not* incrementing s._sum_of_squares
}

 I'd just call that bad design, I wouldn't reference a variable 
like that  unless it's returned const or I don't care about if 
anything else accesses it. Since T/_t is private you shouldn't be 
giving access to them without a good reason.


...Whereas with memberspaces we can add that extra layer of 
encapsulation:

struct S
{
    private T _t;
    private int _sum_of_squares;

    memberspace prop
    {
        ref const(T) opCall() const
        {
            return _t;
        }

 So this one's allowed a const get return....

        void add_twice(int v)
        {
            _sum_of_squares += (2 * v)^2; // Yippee!
            return _t.add_twice(v);
        }
    }
}

 Hmmm curiously the above previous example didn't include 
add_twice outside of T. had it of and had a const get I'm sure 
these would be about the same.

 I'll your example(s) here reflect a bad/different design rather 
than why namespaces should be used.

 Besides, wasn't namespaces in D handled due to initial modular 
setup and alias?