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

Groups > comp.lang.java.programmer > #27391 > 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" Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-23 17:52 -0400
    Re: building "path expressions" Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-01-23 23:24 -0800

#27391 — Re: building "path expressions"

On 01/23/2014 12:37 PM, 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.
>
>    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
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [next] | [standalone]

#27396

In article <qagEu.306828$Rp6.30235@fx15.iad>,
 Arved Sandstrom <asandstrom2@eastlink.ca> wrote:

> On 01/23/2014 12:37 PM, 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.
> >
> >    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.)

[toc] | [prev] | [standalone]

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

csiph-web