Dave -

Thanks for responding.

Yes, it is a human issue and not a compiler issue.

1) For me, having the classes defined within the method
enhances readability. The nesting tells the reader that outside
of the context of this method, the class is inaccessible and
therefore irrelevant. And when viewing the class in its
entirety, the outer scope is not "polluted" with something that
doesn't really belong there. To me this is no more than another
application of the same principle that guides us to use local
variables rather than the more global instance variables -- in
fact, classes defined within a method or called local classes.
It is also similar to declaring something private -- it is a
more precise definition of the actual scope of use.

In the cases I referred to, the class definitions were really
the only thing happening in the method, other than the
instantiation of them. So they didn't take away from the
readability of the method, IMO.

2) Testing is an interesting point. In this case, they were
trivial classes used to construct a GUI object; the behavior of
that object was tested in other ways.

----

Regarding the question about memory allocation, it *does*
matter in Java, IMO. Consider that common practice is to create
an object outside of a loop, even though its scope could be
defined more narrowly by creating it *inside* the loop. So we
are *already* compromising (albeit in a small way) precision of
communication for the sake of performance. We're not going to
take the drastic step of switching languages because of a few
loops, but we'd also like to not do something stupid.

Regarding the message to Brian Goetz, here is something that
might work:

----

We understand that the allocation and collection of short lived
objects is much cheaper than that of longer lived objects. We
also understand that we don't need to be as concerned as we
were in earlier days with coding for performance.

Nevertheless, in writing our programs it would be helpful to
have some idea as to the relative magnitudes of the costs, so
that we can avoid severely impacting performance, especially if
the approach we chose was intended to improve that performance.

So, what kinds of differences are we talking about? How many
orders of magnitude? Just how cheap is the allocation and
collection of a short-lived object (not counting its
construction)?

One case we discussed was a loop. How much time and memory
allocation would need to happen inside of the loop to make it
likely that that an object created outside the loop would *not*
be considered a short lived object?

These questions are not precise, and we understand that the
answers would also not be precise. Even imprecise information
would be helpful, though, as we currently have next to none.

Thanks.

----

- Keith


--- In novajug@yahoogroups.com, David Bock <dbock@...> wrote:
>
> Keith,
>
> Regarding garbage collection and memory allocation, the speaker you
> referred to earlier was Brian Goetz. If you summarize the thread into
> a concise question for him, I'll forward it on. But in short, I
> suspect his answer for this situation would be something along the
> lines of, "small short-lived object creation is a non-issue for Java
> performance. If you are in a coding situation where you think that
> matters for the performance of your algorithm, you should probably be
> in a language other than Java in the first place".
>
> Back to your initial question, this isn't a matter for the compiler
> - I suspect almost the same bytecode would be produced in both cases,
> with the only difference being related to the scope they could be
> created on. So if the difference in coding style isn't for the
> compiler, who is it for? It is for us, the humans maintaining that
> code. So I would ask you:
>
> 1) Does narrowing the definition in scope make it more or less
> readable to you? (Does the locality of the definition make it more
> relevant, or 'in the way' of the comprehension of the method?)
>
> 2) In what scope is it more or less testable? If defining it in such a
> place means I can't write unit tests and get code coverage for it,
> that would be a major drawback, even if it led to in-place
> understanding.
>
> -db