query regarding static metods

[srikanthyellanki]

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

 

[Chris Dollin]

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 inner
object to point to?

 

[Lew]

Because they don't have access to an instance for the inner
object to point to?

That is correct!

-- Lew

 

[Chris Uppal]

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

-- chris

 

[Daniel Pitts]

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

================

-- chris

Funny, I wrote a blog (internal to my work place) about this exact
syntax.

I also wrote that I would avoid it at all costs.

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

Okay, maybe its weird. but would you rather use "new
instance.Inner(32)"?

 

[Chris Uppal]

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.

-- chris

 

[Mike Schilling]

Hmm... Yes, I see your point.



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.

 

[Daniel Pitts]

Hmm... Yes, I see your point.


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.

-- chris

So, 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 classes
COULD be decoupled eventually. However, if you have two coupled
classes, and one is exclusively created inside the other, why not take
advantage of the implicit Outer.this.

 

[Chris Uppal]

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

-- chris

 

[Daniel Pitts]

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

-- chris

I think the effect is mostly intuitive, which allows people to write
functioning code without worrying about little things like "Wait, how
come I can access my outer classes members?"

Well, I don't know. I think that Java should have syntax sugar for
Runnable and/or Callable.

SwingUtilities.invokeLater(run{doThings();});
vs
SwingUtilities.invokeLater(new Runnable() { public void run()
{doThings();}});