building "path expressions" topic

On 1/23/2014 11:37 AM, Stefan Ram wrote:
> When creating an interface for a library, sometimes one wants the user
> to see nesting in a »path expression«, like for example »a.b.c.d.e.f.g.h«
> to convey the idea that h is a part of g, which is a part of f, and so on.
>
> I think it is funny that one can use either package names /or/ nested
> classes /or/ fields to implement such a path, without this choice being
> visible in the »path expression«. For example, one posssibility to
> implement a »path expression« »a.b.c.d.e.f.g.h« might be:
>
> package a.b.c;
> class G { int h = 8; }
> class F { G g = new G(); }
> class d { static class e { static F f = new F(); }}
> public final class Main
> { public static void main( String[] args )

ITYM "java.lang.String[]", also "class a.b.c.G",
"a.b.c.G g = new a.b.c.G();", etc. ;-)

> { java.lang.System.out.println( a.b.c.d.e.f.g.h ); }}

If it seems funny to you, your sense of humor is more
finely developed than mine. :)

Just for the record, note that the "a.b.c" part is
different from the rest. Packages have no hierarchical
relationship, that is, package "a.b.c" is unrelated to
"a.b.x" and even to "a.b". To put it another way, the
path "a.b.c.d.e.f.g.h" has six elements ("a.b.c" and five
more), not eight.

--
Eric Sosman
(E-Mail Removed)d