why static methods of outer class cannot create the object of non-static inner class?

srikanthyellanki@gmail.com wrote:> why static methods of outer class cannot create the object of non-> static inner class?Because they don't have access to an instance for the innerobject to point to?-- Chris "rhetorical hedgehog" Dollin"Who are you? What do you want?" /Babylon 5/

srikanthyellanki@gmail.com wrote:> >> why static methods of outer class cannot create the object of non->> static inner class?Chris Dollin wrote:> Because they don't have access to an instance for the inner> object to point to?That is correct!-- Lew

srikanthyellanki@gmail.com wrote:> why static methods of outer class cannot create the object of non-> static inner class?They can, but you have to pass an instance of the class to every constructorused in that way.  The syntax for doing that is wierd (and pointlessly so, IMO)but is well-defined:  E.g.================class Outer{ class Inner {  Inner(int param)  {  } } static void test() {  Outer instance = new Outer();  Inner inner = instance.new Inner(42); }}================    -- chris

On Mar 14, 11:42 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-THIS.org> wrote:> srikanthyella...@gmail.com wrote:> > why static methods of outer class cannot create the object of non-> > static inner class?>> They can, but you have to pass an instance of the class to every constructor> used in that way.  The syntax for doing that is wierd (and pointlessly so, IMO)> but is well-defined:  E.g.>> ================> class Outer> {>  class Inner>  {>   Inner(int param)>   {>   }>  }>>  static void>  test()>  {>   Outer instance = new Outer();>   Inner inner = instance.new Inner(42);>  }}>> ================>>     -- chrisFunny, I wrote a blog (internal to my work place) about this exactsyntax.I also wrote that I would avoid it at all costs.The syntax makes sense if you think about the order symbols areresolved.  Eventually, the compiler will look for an implied "this.",which would lead to "this.new Inner(42)";Okay, maybe its weird. but would you rather use "newinstance.Inner(32)"?

Daniel Pitts wrote:> The syntax makes sense if you think about the order symbols are> resolved.  Eventually, the compiler will look for an implied "this.",> which would lead to "this.new Inner(42)";Hmm... Yes, I see your point.> Okay, maybe its weird. but would you rather use "new> instance.Inner(32)"?I'd rather the code looked as if it were doing what it is /acutally/ doing.  Sothe inner class's constructor took an /explicit/ instance of the enclosingclass as its first parameter.    -- chris

"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote in message news:45f9b0a0$0$761$bed64819@news.gradwell.net...> Daniel Pitts wrote:>>> The syntax makes sense if you think about the order symbols are>> resolved.  Eventually, the compiler will look for an implied "this.",>> which would lead to "this.new Inner(42)";>> Hmm... Yes, I see your point.>>>> Okay, maybe its weird. but would you rather use "new>> instance.Inner(32)"?>> I'd rather the code looked as if it were doing what it is /acutally/ > doing.  So> the inner class's constructor took an /explicit/ instance of the enclosing> class as its first parameter.Then the usual case (using the implied "this") would require an explicit "this".And would you also require the inner class constructors to declare the enclosing instance as the first parameter?  If so, they're forced to declare a parameter that at least 90% would never use; if not, there's a mismatch between the new-expression and the constructor it invokes. 

On Mar 15, 12:56 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-THIS.org> wrote:> Daniel Pitts wrote:> > The syntax makes sense if you think about the order symbols are> > resolved.  Eventually, the compiler will look for an implied "this.",> > which would lead to "this.new Inner(42)";>> Hmm... Yes, I see your point.>> > Okay, maybe its weird. but would you rather use "new> > instance.Inner(32)"?>> I'd rather the code looked as if it were doing what it is /acutally/ doing.  So> the inner class's constructor took an /explicit/ instance of the enclosing> class as its first parameter.>>     -- chrisSo, you'd prefer this:class Outer {    class Inner {    }    Inner getInner() {      return new Inner(this);    }}Hmm, thats broken in more ways than one...how about this:class Outer {    static class Inner {        final Outer outer;        Inner(Outer outer) {            this.outer = outer;        }    }    Inner getInner() {      return new Inner(this);    }}I actually do like the static version a bit better if the classesCOULD be decoupled eventually.  However, if you have two coupledclasses, and one is exclusively created inside the other, why not takeadvantage of the implicit Outer.this.

Daniel Pitts wrote:[me:]> > I'd rather the code looked as if it were doing what it is /acutally/> > doing.  So the inner class's constructor took an /explicit/ instance of> > the enclosing class as its first parameter.[...]> So, you'd prefer this:> class Outer {>     class Inner {>     }>>     Inner getInner() {>       return new Inner(this);>     }> }>> Hmm, thats broken in more ways than one...I don't see how it can be "broken" when that's what is actually happeningtoday.>  However, if you have two coupled> classes, and one is exclusively created inside the other, why not take> advantage of the implicit Outer.this.I have no objection to the implicit reference to the outer object.  Whatdoesn't sit well with me is the implicit /establishment/ of that reference.  Itdoesn't seem that the "pretty" syntax (which tries to hide the connection) isany prettier than the "raw" alternative -- there's not a lot of point insyntactic sugar that isn't even sweet...    -- chris

On Mar 16, 7:05 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-THIS.org> wrote:> Daniel Pitts wrote:>> [me:]>> > > I'd rather the code looked as if it were doing what it is /acutally/> > > doing.  So the inner class's constructor took an /explicit/ instance of> > > the enclosing class as its first parameter.> [...]> > So, you'd prefer this:> > class Outer {> >     class Inner {> >     }>> >     Inner getInner() {> >       return new Inner(this);> >     }> > }>> > Hmm, thats broken in more ways than one...>> I don't see how it can be "broken" when that's what is actually happening> today.>> >  However, if you have two coupled> > classes, and one is exclusively created inside the other, why not take> > advantage of the implicit Outer.this.>> I have no objection to the implicit reference to the outer object.  What> doesn't sit well with me is the implicit /establishment/ of that reference.  It> doesn't seem that the "pretty" syntax (which tries to hide the connection) is> any prettier than the "raw" alternative -- there's not a lot of point in> syntactic sugar that isn't even sweet...>>     -- chrisI think the effect is mostly intuitive, which allows people to writefunctioning code without worrying about little things like "Wait, howcome I can access my outer classes members?"Well, I don't know.  I think that Java should have syntax sugar forRunnable and/or Callable.SwingUtilities.invokeLater(run{doThings();});vsSwingUtilities.invokeLater(new Runnable() { public void run(){doThings();}});