Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Jeff Higgins Newsgroups: comp.lang.java.programmer Subject: Re: building "path expressions" Date: Thu, 23 Jan 2014 16:52:57 -0500 Organization: A noiseless patient Spider Lines: 49 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 23 Jan 2014 21:54:39 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="6b9e92482af47766954d85fb77d372f5"; logging-data="6151"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18nTPjCbvNXDw2yzBazhJ++kQHwRhHGg78=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 In-Reply-To: Cancel-Lock: sha1:zaX3Ono3WlDBTBkk9RfbWElnBuk= Xref: csiph.com comp.lang.java.programmer:27392 On 01/23/2014 04:12 PM, Stefan Ram wrote: > Jeff Higgins writes: >> Do you have an example using some real world names to help me understand? > > In Android programming, they use names like > > R.layout.main > > . »R« is a public final class. »layout« is a nested public static final > class, but when using »R.layout.main«, one cannot know this; »layout« > could be a field as well (usually, one also does not need to know this, > so it's just fine as it is. I am not complaining.). > > The meanings are as follows: > > R the space of automatically-defined constants > R.layout the subspace of layout-related constants > R.layout.main a constant for the layout of the main activity > > The name »R.layout.main« is the »user interface«. It can be > implemented with either a nested static class »layout« or a > field »layout«. It might be even possible to change this > later without breaking too many clients. > > Yes, the class »layout« officially is written with a lower-case »l«. > These Google folks, they do not have any respect. > 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 ) { java.lang.System.out.println( a.b.c.d.e.f.g.h ); }} I guess I'm being dense today. I can't relate your example to your OP. Do Javadocs help?