Possible @property compromise

[Zach the Mystic]

On Saturday, 2 February 2013 at 20:30:26 UTC, Era Scarecrow wrote:
> 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.

I think this belittles just how important that implementation 
detail really is. Without a good design, the thing could be 
prohibitively difficult to implement.

>  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.

 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.

You might as well use the built-in functionality for tagging 
whatever you want private or public, though. Consider this: 
software design doesn't end at language design. There's only so 
much a language can do to encourage good design before it starts 
to feel like it's strong-arming you into certain arbitrary ways 
of doing things. Doing this too much is actually *bad* language 
design.