Groups > comp.lang.java.programmer > #27394

Re: building "path expressions"

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 <jeff@invalid.invalid>
Newsgroups	comp.lang.java.programmer
Subject	Re: building "path expressions"
Date	Thu, 23 Jan 2014 17:29:53 -0500
Organization	A noiseless patient Spider
Lines	34
Message-ID	<lbs587$im7$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> <lbs32v$607$1@dont-email.me> <path-expressions-20140123230350@ram.dialup.fu-berlin.de>
Mime-Version	1.0
Content-Type	text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding	8bit
Injection-Date	Thu, 23 Jan 2014 22:31:35 +0000 (UTC)
Injection-Info	mx05.eternal-september.org; posting-host="6b9e92482af47766954d85fb77d372f5"; logging-data="19143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195ysYRxBMOmaoqzMtfZwMFXWbPxAwxlvE="
User-Agent	Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10
In-Reply-To	<path-expressions-20140123230350@ram.dialup.fu-berlin.de>
Cancel-Lock	sha1:PZplB8yxSnYCZcElAyRi8iaRkcQ=
Xref	csiph.com comp.lang.java.programmer:27394

Show key headers only | View raw

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

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