From: Daniel Pitts on
On 4/28/2010 5:05 PM, Stefan Ram wrote:
> Daniel Pitts<newsgroup.spamfilter(a)virtualinfinity.net> writes:
>> Strangely, I know there is syntax for the reverse proposition. Creating
>> an Inner instance from an Outer:
>> class X {
>> void bump(Outer z) {
>> z.i++;
>> Outer.Inner in = z.new Inner();
>> }
>> }
>> I could find no way to access z from in though.
>
> class Main
> {
> class Inner
> { public Inner()
> { java.lang.System.out.println( Main.this ); }}
>
> static void method( final Main main )
> { Main.Inner in = main.new Inner(); }
>
> public static void main( final java.lang.String[] args )
> { method( new Main() ); }}
>
> Main(a)146ab72
>
That doesn't solve the problem any better than the OP's approach.

There is no way to directly access Main.this from outside of the Inner
class. It is basically a private member (internally called this$0 I
believe)

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Mike Schilling on
Daniel Pitts wrote:

>
> There is no way to directly access Main.this from outside of the Inner
> class. It is basically a private member (internally called this$0 I
> believe)

Exactly. The fact that the class has an enclosing member is private
behavior. The class can expose it to the public if it likes, but is under
no obligation to do so. And I agree, on reflection, that it's a bit weird
that there's a standard

new outer.Inner();

syntax, even though, again, the enclosing class chooses to expose it to the
world by making the constructor public. It would be more consistent if only
the enclosing class could create an instance of the inner one, and, if it
wanted to make that ability publicly available, would have to create a
public method to do so.


From: Scott A. Hightower on
"Mike Schilling" <mscottschilling(a)hotmail.com> wrote in message
news:hrd40f$v6p$1(a)news.eternal-september.org...
> Daniel Pitts wrote:
>
>>
>> There is no way to directly access Main.this from outside of the Inner
>> class. It is basically a private member (internally called this$0 I
>> believe)
>
> Exactly. The fact that the class has an enclosing member is private
> behavior. The class can expose it to the public if it likes, but is under
> no obligation to do so. And I agree, on reflection, that it's a bit weird
> that there's a standard
>
> new outer.Inner();
>
> syntax, even though, again, the enclosing class chooses to expose it to
> the world by making the constructor public. It would be more consistent
> if only the enclosing class could create an instance of the inner one,
> and, if it wanted to make that ability publicly available, would have to
> create a public method to do so.
>

Maybe it was one of those things that was easy to do after they figured out
how to make inner classes work.

But the visibility doesn't have to be public. Package-private and protected
will do. Anything goes within a package*. And if a base class implementer
doesn't feel like creating eleventy-eight methods so sub-classes can request
just the right flavor of schranitzulator.

*Disclaimer: I myself don't relax standards between members of the same
package, but I understand some people do.


From: Daniel Pitts on
On 4/29/2010 5:22 PM, Stefan Ram wrote:
> Daniel Pitts<newsgroup.spamfilter(a)virtualinfinity.net> writes:
>>>> void bump(Outer z) {
>>>> z.i++;
>>>> Outer.Inner in = z.new Inner();
>>>> I could find no way to access z from in though.
>> That doesn't solve the problem any better than the OP's approach.
>
> I replied to �access z /from/ in� in the sense of �from
> /within/ "in"� (at least this is a permissible reading).
> I did not recall the OP while writing my reply.

You hadn't needed to look far to find it, I had quoted it. Context is
often provided because it changes or clarifies the meaning.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>