From: Daniel Pitts on 29 Apr 2010 16:10 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 29 Apr 2010 19:16 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 29 Apr 2010 20:45 "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 30 Apr 2010 13:14 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/>
First
|
Prev
|
Pages: 1 2 Prev: Reading the BAM or Directory Next: Handling extremely large input files |