query regarding static metods

Thread view:

Enable EMail Alerts

Start New Thread

srikanthyellanki@gmail.com - 14 Mar 2007 12:03 GMT

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

Reply to this Message

Chris Dollin - 14 Mar 2007 13:03 GMT

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

Signature

Chris "rhetorical hedgehog" Dollin
"Who are you? What do you want?" /Babylon 5/

Reply to this Message

Lew - 14 Mar 2007 14:37 GMT

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

That is correct!

-- Lew

Reply to this Message

Chris Uppal - 14 Mar 2007 19:42 GMT

> 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

Reply to this Message

Daniel Pitts - 14 Mar 2007 22:55 GMT

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-
[quoted text clipped - 24 lines]
>
> -- 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)"?

Reply to this Message

Chris Uppal - 15 Mar 2007 20:56 GMT

> 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

Reply to this Message

Mike Schilling - 15 Mar 2007 23:01 GMT

>> The syntax makes sense if you think about the order symbols are
>> resolved. Eventually, the compiler will look for an implied "this.",
[quoted text clipped - 9 lines]
> 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.

Reply to this Message

Daniel Pitts - 15 Mar 2007 23:59 GMT

On Mar 15, 12:56 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:

> > The syntax makes sense if you think about the order symbols are
> > resolved. Eventually, the compiler will look for an implied "this.",
[quoted text clipped - 10 lines]
>
> -- 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.

Reply to this Message

Chris Uppal - 16 Mar 2007 15:05 GMT

[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 {
[quoted text clipped - 7 lines]
>
> 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

Reply to this Message

Daniel Pitts - 16 Mar 2007 18:13 GMT

On Mar 16, 7:05 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:

> [me:]
>
[quoted text clipped - 28 lines]
>
> -- 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();}});

Reply to this Message

query regarding static metods

Free Magazines