Home » Newcomers » Newcomers » difference in scope of variable depending on code location(difference in scope of variable depending on code location)
|
| Re: difference in scope of variable depending on code location [message #661735 is a reply to message #661734] |
Sat, 26 March 2011 22:07   |
|
On 2011.03.26 15:51, Michael wrote:
> I am confronted with a difference in the scope of a variable or object
> when I build my application in a single file versus when I put
> individual classes in separate files.
>
> My code is arranged do that my top level class A creates a second class
> B. The class definition for B is included inside class A and so any
> instance variables for A can be seen and used in B.
>
> Now if I remove the class definition for B and put it in a separate
> file, I can no longer see A's instance variables.
> In particular I am trying to pass my button handler an accumulator so I
> can form a number of digits. The accumulator is defined in a separate
> object created in the top level class A. B is the button handler, stored
> in a separate file.
>
> I do not want to include all classes in a monolithic file and it
> frustrates me that I have to make a code adaptation to allow for better
> code organization. Right now I have the accumulator defined as static
> and then just create another object in the button handler to reference
> it. Is there a better way?
>
> (I apologize for terminology lapses, I am a bit rusty...)
>
> thanks,
>
> Michael
While there are many excellent software engineers answering questions in
this forum, it's really for answering questions on Eclipse IDE
installation, use, etc. Assuming yours is a Java (and not C++) question,
you'd do better off using stackoverflow.com or Java Ranch.
|
|
| |
| Re: difference in scope of variable depending on code location [message #661790 is a reply to message #661771] |
Sun, 27 March 2011 21:10 |
|
On 2011.03.27 11:35, Michael wrote:
> Russell,
>
> Thanks for the response.
> The reason I considered this an Eclipse problem is because I get two
> different behaviors while using Eclipse. I am looking for a way to
> configure Eclipse so the scope of a variable is what I think is correct.
>
> Eclipse allows the scope of a variable to exist in objects invoked when
> they are invoked within the top object. At least this is true when the
> classes are described within a single file. Remove one of the classes
> into a separate file within Eclipse, and the scope does not exist, even
> though the object is instantiated from within the top level.
>
> Perhaps I am missing something but Eclipse is changing it behavior, not
> the Java code.
Bugs can always happen. I have never witnessed a situation in which
Eclipse modified Java behavior. Of course, if you use an IDE from day
one in a new language, you might identify such errant behavior with the
language and that could be my case. Best of luck.
|
|
| |
| Re: difference in scope of variable depending on code location [message #662468 is a reply to message #661734] |
Wed, 30 March 2011 17:49 |
 Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
On 3/26/11 5:51 PM, Michael wrote:
> I am confronted with a difference in the scope of a variable or object
> when I build my application in a single file versus when I put
> individual classes in separate files.
>
> My code is arranged do that my top level class A creates a second class
> B. The class definition for B is included inside class A and so any
> instance variables for A can be seen and used in B.
>
> Now if I remove the class definition for B and put it in a separate
> file, I can no longer see A's instance variables.
> In particular I am trying to pass my button handler an accumulator so I
> can form a number of digits. The accumulator is defined in a separate
> object created in the top level class A. B is the button handler, stored
> in a separate file.
>
> I do not want to include all classes in a monolithic file and it
> frustrates me that I have to make a code adaptation to allow for better
> code organization. Right now I have the accumulator defined as static
> and then just create another object in the button handler to reference
> it. Is there a better way?
>
> (I apologize for terminology lapses, I am a bit rusty...)
I think we'd need to see the code in order to determine what's going on.
In general, if B is a Member Class of A (meaning, it's defined as a
nested class, inside class A, not just in the same file as A), then it's
logical that when you move it out into a separate file (which is also
making it a top-level class rather than a member of A), it can't access
A's internal state.
Here's an example of B being a member class of A:
public class A {
class B {
}
}
Alternatively, here's an example of A and B being "independent" but
contained in the same physical file (Java allows this, as long as
there's only one public class, but it's strongly discouraged):
public class A {
}
class B {
}
Which is your situation? Better yet, show us your code.
Eric
|
|
|
| Re: difference in scope of variable depending on code location [message #662483 is a reply to message #662468] |
Wed, 30 March 2011 19:06 |
Michael 
Messages: 3
Registered: March 2011 |
Junior Member |
|
|
| Eric Rizzo wrote on Wed, 30 March 2011 13:49 |
In general, if B is a Member Class of A (meaning, it's defined as a
nested class, inside class A, not just in the same file as A), then it's
logical that when you move it out into a separate file (which is also
making it a top-level class rather than a member of A), it can't access
A's internal state.
Here's an example of B being a member class of A:
public class A {
class B {
}
}
Alternatively, here's an example of A and B being "independent" but
contained in the same physical file (Java allows this, as long as
there's only one public class, but it's strongly discouraged):
public class A {
}
class B {
}
|
Thanks to Eric, I think he has found the flaw in my logic.
I did exactly as you described, moving a member class, B in this case, into a separate file. As you say, it becomes a top level class and is no longer a member of A. My failed logic was that since it was instantiated in the top level class A, then the scope of A's variables should be visible in B.
I guess I need to research in the language definition on how to make that so, which is beyond the scope, no pun intended, of this forum.
|
|
|
| Re: difference in scope of variable depending on code location [message #662722 is a reply to message #662483] |
Thu, 31 March 2011 16:17 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
On 3/30/11 3:06 PM, Michael wrote:
> Eric Rizzo wrote on Wed, 30 March 2011 13:49
>> In general, if B is a Member Class of A (meaning, it's defined as a
>> nested class, inside class A, not just in the same file as A), then
>> it's logical that when you move it out into a separate file (which is
>> also making it a top-level class rather than a member of A), it can't
>> access A's internal state.
>>
>> Here's an example of B being a member class of A:
>>
>> public class A {
>> class B {
>> }
>> }
>>
>> Alternatively, here's an example of A and B being "independent" but
>> contained in the same physical file (Java allows this, as long as
>> there's only one public class, but it's strongly discouraged):
>>
>> public class A {
>> }
>> class B {
>> }
>
>
> Thanks to Eric, I think he has found the flaw in my logic.
> I did exactly as you described, moving a member class, B in this case,
> into a separate file. As you say, it becomes a top level class and is no
> longer a member of A. My failed logic was that since it was instantiated
> in the top level class A, then the scope of A's variables should be
> visible in B.
> I guess I need to research in the language definition on how to make
> that so, which is beyond the scope, no pun intended, of this forum.
>
There are several strategies for dealing with that situation. Here's
one: when A creates an instance of B, it can pass itself as an argument,
which B can store as a member variable and use to access methods from A.
public class A {
private String someData;
protected String getSomeData() {
return someData;
}
// somewhere in A's code, create a B like this:
new B(this);
}
class B {
private A myA;
public B(A someA) {
this.myA = someA;
}
// somewhere in B's code, use A like this:
myA.getSomeData();
}
That's essentially what is happening under the covers by the compiler
when B is a member class of A.
Hope this helps,
Eric
|
|
|
Goto Forum:
Current Time: Wed May 15 04:59:14 GMT 2024
Powered by FUDForum. Page generated in 0.10474 seconds |
] 
Search
Help
Register
Login
Home
