Possible @property compromise

[Era Scarecrow]

On Saturday, 2 February 2013 at 18:03:32 UTC, Zach the Mystic 
wrote:
> On Saturday, 2 February 2013 at 06:28:47 UTC, Era Scarecrow
>> It would refuse to compile as a static function can't point to 
>> an instance/parent. I'm convinced you should not be able to 
>> return (or create an instance of) a nested struct outside of 
>> it's level of control or ability to reference properly.
>>
>> Had it not been static on the other hand...
>>
>>            int otherFunction()
>>
>> cc has the same level as c, so the return would be equal to: 
>> _a + _b + cc._c
>
> ... well, this function requires being called with instances of 
> A, B, and C, so I believe it would error on that account. The 
> only way to call this deeply nested thing would be with an 
> instance of A, which makes sense, since it operates on a 
> variable contained in A. It would have to look like:
>
> A a;
> int z = a.b.c.myMemberFunction();
>
> ... to work, I believe.

  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.

  This brings back training when I was on a database/web 
development. There were 4 tiers, the DB, the Query level (with 
all the queries), Logic level, then the GUI level.

  Now something in this was that each level would be separate and 
not know about the other. When you think about it, it makes sense 
since you can swap out one for another. But then I began to 
notice code that broke that very easily. The GUI level would be 
doing stuff like:

   //posted twice, once for html formatting
   <b>Price: $<?db.getPrices.query("select price 
from priceTable where x=x")?></b>

   <b>Price: $<?db.getPrices.query("select price from priceTable 
where x=x")?></b>

  Not a very large example, however it ended up that the gui was 
getting into specifics of variables and function calls in other 
levels that it shouldn't have known about.

  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.