Am I the only one that thinks the scoping rules in Java are pretty
unusual with regard to ActionListeners? In general Java will look for
local variables (in the method) then look outward from there. But, if
you try and declare an ActionListener inside a method and want to use
those method variables, too bad! Far as I can tell, you have to put the
variables all the way out in the class scope. Is there some way around
this that i'm missing? I need my ActionListener to access a stupid
temp. value inside the method, and making that a class, rather then
method, variable seems pretty obnoxious.
VisionSet - 17 Mar 2006 18:11 GMT
> Am I the only one that thinks the scoping rules in Java are pretty
> unusual with regard to ActionListeners? In general Java will look for
[quoted text clipped - 5 lines]
> temp. value inside the method, and making that a class, rather then
> method, variable seems pretty obnoxious.
Declare the variable final.
You are forced to this with method scoped classes because the objects of
this class out live the local variable, so the variable reference value is
copied, and the compiler wants to make sure it copies the value you intend,
and the easiest way to do this is make sure they can't change.
--
Mike W
Roedy Green - 17 Mar 2006 19:47 GMT
On 17 Mar 2006 09:00:28 -0800, "Jordan Greenberg"
<JordanGreenberg@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>Am I the only one that thinks the scoping rules in Java are pretty
>unusual with regard to ActionListeners? In general Java will look for
[quoted text clipped - 5 lines]
>temp. value inside the method, and making that a class, rather then
>method, variable seems pretty obnoxious.
That you can reach out and grab local variables of the enclosing
method so long as they are final is bizarre. It is just syntactic
sugar for passing in the ones you need as parameters. You are not
really accessing them. The method is not even running by the time the
event is triggered.
see http://mindprod.com/jgloss/anonymousclasses.html

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Jordan Greenberg - 17 Mar 2006 20:27 GMT
it is highly bizarre. But if Java refuses to let you pass paramaters to
an ActionListener, or return anything, or modify local method
variables, forces me to make my little method temp. variable a class
variable, or find a much less elegant way to change that variable when
I want it's change to be based on an event in the GUI.
I don't really understand what you mean by the method not running when
the event is triggered. Essentially I have a method which creates a
JDialog, reads some input from it, disposes of the JDialog, and tosses
that data off to an object of another class entirely. As the dialog is
also local to the method, the ActionListner would never be called
outside that method. I suppose I can see how an object of one of these
classes could outlive it's parent method, but that seems like the less
common case to me, the more common case being the object dying along
with its parent method. In this case, of course, I don't see how the
fact that its a method scoped variable matters, as its still just the
parent scope for the object, just as the class scoped variables are
accessable by the method since the class scope is the method's parent
scope.
I suppose it makes more sense to me to assume that people would be
smart enough to not try and access variables in a scope that no longer
exists, rather then eliminate the possibility entirely because the
parent scope *MIGHT* no longer exist.
Oliver Wong - 17 Mar 2006 21:52 GMT
> Essentially I have a method which creates a
> JDialog, reads some input from it, disposes of the JDialog, and tosses
[quoted text clipped - 4 lines]
> common case to me, the more common case being the object dying along
> with its parent method.
I usually use nested classes as delegate methods. That is, I'll want to
provide the source code for the method here, but I don't actually want to
execute it. Rather, I want to give the method to someone else, and they'll
execute it later whenever they feel good and ready to do so.
A very common situation where this is done is to initialize a Swing GUI
app. The code looks basically like this:
<code>
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
initializeGUI();
}
});
}
</code>
Note the method name, "invokeLater", as in this Runnable really will get
run later on, perhaps long after the parent method has finished executing.
A more exotic example might be constructing a method on one computer,
then passing it over the network to another computer, and having it execute
there.
- Oliver
Tony Morris - 17 Mar 2006 23:48 GMT
> Am I the only one that thinks the scoping rules in Java are pretty
> unusual with regard to ActionListeners? In general Java will look for
[quoted text clipped - 5 lines]
> temp. value inside the method, and making that a class, rather then
> method, variable seems pretty obnoxious.
Take a look at the notion of 'closures', then reassess how you feel.
What you have described is merely a syntactical replacement. To access
your local variables from your anonymous local class, you declare them
final. Although this is not truly necessary assuming any language rules,
the fear of 'allocating on the stack' otherwise ensures it.
Scope rules are something very different, and Java has a somewhat
contrived definition of 'definite assignment' (JLS 16 iirc), but this is
intrinsic to the OO paradigm as we currently know it and therefore,
unavoidable (unless, of course you redefine OO - although correct, it is
a huge social engineering challenge).

Signature
Tony Morris
http://tmorris.net/