Icky Nesting

S

Sum

I have a class that looks like this

class ClassNesting {

class Nest1{
class Nest2{
class Nest3{
String str;

String getStr(){
return str;
}
}
}
}

I want to access str in the constructor ClassNesting() to set it. I
don't want to change the access modifiers for anything. I guess I need
to figure the theory out for this. Any help? How can I do that?

Thanks! :)
 
J

Jim Garrison

Sum said:
I have a class that looks like this

class ClassNesting {

class Nest1{
class Nest2{
class Nest3{
String str;

String getStr(){
return str;
}
}
}
}

I want to access str in the constructor ClassNesting() to set it. I
don't want to change the access modifiers for anything. I guess I need
to figure the theory out for this. Any help? How can I do that?

str doesn't exist until an instance of Nest3 is created.
This can only happen at a 'new' expression for Nest3.
Instantiating ClassNesting, Nest1, or Nest2 does NOT
create an instance of Nest3.

Maybe if you explained what you're trying to accomplish
we could help.
 
P

Patricia Shanahan

Sum said:
I have a class that looks like this

class ClassNesting {

class Nest1{
class Nest2{
class Nest3{
String str;

String getStr(){
return str;
}
}
}
}

I want to access str in the constructor ClassNesting() to set it. I
don't want to change the access modifiers for anything. I guess I need
to figure the theory out for this. Any help? How can I do that?

Thanks! :)

Since str is not static, and is declared inside Nest3, each Nest3
instance has its own str.

Talking about "set it" suggests you think there is exactly one str
field. Why? Does something ensure that there is exactly one Nest3
instance, not zero or forty-two?

If all Nest3 instances should use the same value for str, you could make
it a ClassNesting field. The ClassNesting constructor would set it, and
each Nest3 would have access to it.

Patricia
 
S

Sum

Since str is not static, and is declared inside Nest3, each Nest3
instance has its own str.

Talking about "set it" suggests you think there is exactly one str
field. Why? Does something ensure that there is exactly one Nest3
instance, not zero or forty-two?

If all Nest3 instances should use the same value for str, you could make
it a ClassNesting field. The ClassNesting constructor would set it, and
each Nest3 would have access to it.

Patricia

Patricia-
I am not trying to maintain str as a static variable. My intention is
to initialize str in the constructor of ClassNesting. Something like
this:
ClassNesting(String something){
//initialize str to something
}
Jim-
I figured that since Nest3() was essentially a part of ClassNesting I
should be able to access str through an instance of ClassNesting. I
cannot instantiate Nest3 anywhere except as ClassNesting's member
data.

What I want to do is initialize str through the constructor of
ClassNesting to the passed parameter. Thanks for your responses. I
hope you can help me solve this! :)

Let me paste a clearer picture here

class ClassNesting {
class Nest1{
class Nest2{
class Nest3{
String str;

String getStr(){
return str;
}
}
}
}

Nest1.Nest2.Nest3 n3; //I don't really want to do this.

ClassNesting(String s) {

}
static void main(String[] args) {
ClassNesting cn = new ClassNesting("Sumitra");
cn.n3.str = "Hello!"; //Able to access str here like so. Again, not
really what I want to do.

}
 
O

Owen Jacobson

This is almost exactly equivalent to this:

class ClassNesting {
/* ... */
}

class Nest1 {
private final ClassNesting outer;

public Nest1 (ClassNesting outer) { this.outer = outer; }
}

class Nest2 {
private final Nest1 outer;

public Nest2 (Nest1 outer) { this.outer = outer; }
}

class Nest3 {
private final Nest2 outer;

public Nest3 (Nest2 outer) { this.outer = outer; }

String str;
public String getStr () { return str; }
}

In this code, would you expect creating a new ClassNesting instance to
also automatically create a new Nest3?

If so, why?

That above example is as close as possible to what the compiler
generates for you.
Patricia-
I am not trying to maintain str as a static variable. My intention is
to initialize str in the constructor of ClassNesting.

*what* str? Look at the example I made above.
 
J

Jim Garrison

Sum said:
Jim-
I figured that since Nest3() was essentially a part of ClassNesting I
should be able to access str through an instance of ClassNesting. I
cannot instantiate Nest3 anywhere except as ClassNesting's member
data.

You have DECLARED Nest3 but not instantiated anything. Since Nest3
is declared inside other classes and is not static it is in a privileged
position with regards to accessing members of enclosing class instances
(I don't remember the rules and would have to research it). However,
just declaring it there does not create an instance of it when you
instantiate an enclosing class. There's a big difference between
declaration and instantiation.
 
P

Patricia Shanahan

Sum wrote:
.....
Let me paste a clearer picture here

class ClassNesting {
class Nest1{
class Nest2{
class Nest3{
String str;

String getStr(){
return str;
}
}
}
}

Nest1.Nest2.Nest3 n3; //I don't really want to do this.

Even that would not be enough to make the assignment to str work. You
would have had to initialize n3 to refer to some instance of Nest3.
ClassNesting(String s) {

}
static void main(String[] args) {
ClassNesting cn = new ClassNesting("Sumitra");
cn.n3.str = "Hello!"; //Able to access str here like so. Again, not
really what I want to do.

}

The approach you are taking seems to be based on some misconceptions
about the behavior and use of member classes.

Why don't you explain the design problem you are trying to solve? That
way, there would be some chance someone could suggest a solution, rather
than just saying "That won't work.".

Patricia
 
J

Joshua Cranmer

Owen said:
That above example is as close as possible to what the compiler
generates for you.

No, using this$0 is closer. I've dumped the javap output and seen it for
myself.
 
O

Owen Jacobson

No, using this$0 is closer. I've dumped the javap output and seen it for
myself.

Right, but you can't use $ in identifiers to code you pass to javac --
they're reserved for generated code. The semantics are the same,
except for visibility.
 
O

Owen Jacobson

Then, why do I remember having done so?

What do you know, I learn something new every day. Note that section
3.8 of the JLS does suggest using it is a bad idea.

"The $ character should be used only in mechanically generated source
code or, rarely, to access preexisting names on legacy systems."
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top