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.
