Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #27386 > unrolled thread

Re: building "path expressions"

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: building "path expressions" Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-01-23 11:50 -0500

#27386 — Re: building "path expressions"

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
esosman@comcast-dot-net.invalid

[toc] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web