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

Groups > comp.lang.java.programmer > #27388 > 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" 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

#27388 — Re: building "path expressions"

On 01/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.

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

[toc] | [next] | [standalone]

#27390

On 01/23/2014 03:27 PM, Jeff Higgins wrote:
> On 01/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.
>
> 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)

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

[toc] | [prev] | [next] | [standalone]

#27392

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?

[toc] | [prev] | [next] | [standalone]

#27394

On 01/23/2014 05:04 PM, Stefan Ram wrote:
> Jeff Higgins <jeff@invalid.invalid> writes:
>> 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.
>

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".

[toc] | [prev] | [next] | [standalone]

#27395

On 1/23/2014 2:29 PM, Jeff Higgins wrote:
>
> 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.

[toc] | [prev] | [standalone]

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

csiph-web