Using memberspaces for a property-like syntax and more

[TommiT]

On Sunday, 3 February 2013 at 01:45:14 UTC, Era Scarecrow wrote:
> 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.

I agree that the example of mine which used @property attribute 
is a bad design, and that's exactly my point. The point is that 
it's impossible to create a good design of 'S' with @property 
attribute, if the interface is required to have a property-like 
syntax. And if the interface isn't required to provide a 
property-like syntax, then what are we even talking about?

In order to implement the same level of encapsulation as there is 
in the example of mine which uses memberspaces, you'd probably 
prefix the method names with the name of the property to make a 
hint to the user that those things are linked to each other. That 
indicates a failure in what @property attribute tries to 
accomplish. Anyway, it would look something like this:

struct S
{
     private T _t;
     private int _sum_of_squares;

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

     // This method here shows that our attempts at creating
     // property semantics with @property attribute has failed:
     void prop_add_twice(int v)
     {
         _sum_of_squares += (2 * v)^^2;
         _t.add_twice(v);
     }
}


On Sunday, 3 February 2013 at 01:45:14 UTC, Era Scarecrow wrote:
>  Besides, wasn't namespaces in D handled due to initial modular 
> setup and alias?

Module-level and type-level are two different things.