Possible @property compromise

[Era Scarecrow]

On Sunday, 3 February 2013 at 02:55:44 UTC, Zach the Mystic wrote:
> On Saturday, 2 February 2013 at 20:30:26 UTC, Era Scarecrow 
> wrote:
>> Yes, it should be callable that way since it knows where a is 
>> at. However I would think a nested struct is more a 
>> implementation detail.
>
> I think this belittles just how important that implementation 
> detail really is. Without a good design, the thing could be 
> prohibitively difficult to implement.
>
> From what I understand generally, good encapsulation is a 
> difficult design problem. I don't think you're alone.
>
>> In short, nested structs would only be accessible (and 
>> passable) inside the struct that made it. Meaning that most 
>> likely the methods that work with it, and the struct itself 
>> should be private.
>
> Well, if you want access to a struct from outside, save 
> yourself the time and put it outside to begin with. A nested 
> struct of course is directly related to the entity it finds 
> itself in. My pet metaphor is struct Dog containing struct 
> Tail. It would definitely be illogical to put the Tail outside 
> the Dog.

  Agreed 100%, Although a second (instance of) Dog may want to 
come about and them sniff tails. That's outside access, but it's 
still within the limits of the Dogs. In those cases a context 
pointer could be acceptable as long as it's ensuring the data 
exists (and can't return it from the function); But overwriting 
one instance with a different context pointer of another could 
have very curious side effects depending on design.

   struct Dog {
     int id;
     struct Tail {
       string colorOf = "Black"; //just data.
       int getId() { return id; }
     }
     Tail tail;

     void func(ref Dog rhs) {
       //tail2 retains context pointer to rhs.
       Tail tail2 = rhs.tail;

       writeln(tail.getId());   //5
       writeln(tail2.getId());  //10
     }
   }

   Dog dog1 = Dog(5);
   Dog dog2 = Dog(10); dog2.tail.colorOf = "White";

   dog1.func(dog2);

   //context pointer of d2 thrown away after copy,
   //unless opAssign declared and does something.
   dog1.tail = dog2.tail;

   assert(d1.id == 5);   //untouched
   assert(d1.tail.colorOf == "White");


   At which case the tail if it's allowed to be copied should be 
related but not strictly required to be updated or relied on Dog 
for behavior.

  Guess it takes a few rules and experiments to find the right 
balance of accessibility vs reliability vs flexibility.