building "path expressions"

[Stefan Ram]

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 ); }}

 

[Eric Sosman]

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.

 

[markspace]

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

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

Well I'm not sure what you find "funny" here; possibly that . is used
to both separate a name in package name, and to access a field?

It's not the first example of operator overloading in a language. In
Java, the + operator means integer addition, floating point addition
(two very different things) as well as string concatenation.

But I don't find it funny, merely practical and sensible. Natural
languages use the same word to mean different things as well, why should
mathematical languages be any different?

 

[Jeff Higgins]

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.

Do you have an example using some real world names to help me understand?
Can the names help the user to visualize the nesting, or is some other
markup required?
I'm drawing a complete blank here.

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 ); }}

 

[Jeff Higgins]

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.

Do you have an example using some real world names to help me understand?
Can the names help the user to visualize the nesting, or is some other
markup required?
I'm drawing a complete blank here.

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 ); }}

java.lang.System.out.println(
test.ram.Automobile.Commands
.StartCockpitVoiceRecorder.GetOBD.Devices.GetSecondaryAirBag.Fire)

!!!! @#$%^&* @#%$%^&***

 

[Stefan Ram]

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.

 

[Arved Sandstrom]

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 ); }}

If you nest that deep, stand by for a lot of NPEs.

AHS

 

[Jeff Higgins]

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?

 

[Stefan Ram]

I can't relate your example to your OP.

The OP had the »path expression« (more official lingo:
»qualified name«) »a.b.c.d.e.f.g.h« while the follow up had
the »path expression« »R.layout.main«.

For another example: in Bioinformatics, one might want the
information about humans in a library to be accessible under

Animalia.Chordata.Mammalia.Primates.Hominidae.Hominini.Homo.Homo_sapiens

, and one still can be free to decide what part of this path
is a package, class or field.

 

[Jeff Higgins]

The OP had the »path expression« (more official lingo:
»qualified name«) »a.b.c.d.e.f.g.h« while the follow up had
the »path expression« »R.layout.main«.

For another example: in Bioinformatics, one might want the
information about humans in a library to be accessible under

Animalia.Chordata.Mammalia.Primates.Hominidae.Hominini.Homo.Homo_sapiens

, and one still can be free to decide what part of this path
is a package, class or field.

That's a fairly spare requirements document.

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.

a.b.c.e.f.g.h
The nesting is clear except as Eric Sosman noted, not in the package name.

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:

Why would one want type information visible in your "path expression".

 

[markspace]

Why would one want type information visible in your "path expression".

Removing the operator overloading would convey type information.

- binds package to class.
^ binds class to subclass
: binds class to field

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(); }}

becomes

a.b.c-d:e^f:g:h

But no one thinks that way, or wants to. The type information is there,
but the example really isn't better for it. Better to use names that
convey information than to make funny symbols that look like your cat
walked on the keyboard.

R.layout.main is an unfortunate example of not using names to properly
convey information. It's a quirk of working with actual human beings
that we all have to put up with this sort of thing on occasion.

 

[Kevin McMurtrie]

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 ); }}

If you nest that deep, stand by for a lot of NPEs.

AHS

I do find myself making crazy deep static inner classes when binding
complex JSON to classes.

As for the NPEs, I'm a fan of 'final' fields, especially if they're
public. There's no chance for them to be uninitialized due to errors or
lack of proper state transitions. Mutation requires building a new
object, but that penalty can be offset by guaranteeing that object
sharing is safe. You can also de-dupe objects of low cardinality using
an object pool. Quickly replacing a duplicate object with an immutable
pooled object helps the duplicate to be GCed efficiently from within the
young generation heap.

(I'm not proposing any kind of religious effort here. I consider
mutable classes quite normal.)