Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #27392
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: building "path expressions" |
| Date | 2014-01-23 16:52 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <lbs32v$607$1@dont-email.me> (permalink) |
| References | <path-expressions-20140123173039@ram.dialup.fu-berlin.de> <lbru26$8dv$1@dont-email.me> <nesting-20140123220949@ram.dialup.fu-berlin.de> |
On 01/23/2014 04:12 PM, Stefan Ram wrote:
> Jeff Higgins <jeff@invalid.invalid> 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?
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: building "path expressions" Jeff Higgins <jeff@invalid.invalid> - 2014-01-23 15:27 -0500
Re: building "path expressions" Jeff Higgins <jeff@invalid.invalid> - 2014-01-23 16:11 -0500
Re: building "path expressions" Jeff Higgins <jeff@invalid.invalid> - 2014-01-23 16:52 -0500
Re: building "path expressions" Jeff Higgins <jeff@invalid.invalid> - 2014-01-23 17:29 -0500
Re: building "path expressions" markspace <markspace@nospam.nospam> - 2014-01-23 15:33 -0800
csiph-web