List or Iterator

[Tom Anderson]

All good points. Of course, when any of them apply, you've also got to
consider "Might I want to use this class in another method? If so, I
might as well make it a full-fledged nested class." Anyway, had local
classes never been invented, I doubt we'd miss them.

I didn't realise we did have them! When were they added?

tom

 

[Tom Anderson]

In Java, the solution to this usually boils down to anonymous classes:

Iterable<Node> getChildrenIterable() {
final Iterator<Node> it= getChildrenIterator();
return new Iterable<Node>() {
public Iterator<Node> iterator() { return it; }
}
}

Right. My question, really, is is this reasonable? For instance, this:

Iterable<Node> children = foo.getChildrenIterable();
for (Node n: children) {
System.out.println(n);
}
for (Node n: children) {
System.out.println(n);
}

Will print different things in the two identical loops - all the children
the first time, and nothing the second time. Would it be better to throw
an exception from iterator() if it's called more than once? Would it be
better to do what i was thinking of:

Iterable<Node> getChildrenIterable() {
return new Iterable<Node>() {
public Iterator<Node> iterator() {
return getChildrenIterator();
}
}
}

Which *can* be called multiple times?

Would it be better not to return an Iterable, since that's misleading, and
rather return an Iterator, but to provide a utility method:

public class IteratorTools {
private IteratorTools() {}
/**
Use this as a static import. You are not expected to like the name!
*/
public static <T> Iterable<T> in(final Iterator<T> it) {
return new Iterable<T>() {
public Iterator<T> iterator() {
return it;
}
}
}
}

So you can do:

Iterator<Node> children;
for (Node n: in(children)) {
// etc
}

That is, shift the responsibility for Iterable-ifying the Iterator to the
caller?

tom

 

[Lew]

I didn't realise we did have them! When were they added?

February, 1997.

 

[Lew]

Would it be better to do what i [sic] was thinking of:

Iterable<Node> getChildrenIterable() {
        return new Iterable<Node>() {
                public Iterator<Node> iterator() {
                        return getChildrenIterator();
                }
        }

}

Which *can* be called multiple times?

Would it be better not to return an Iterable, since that's misleading,

There's nothing misleading about what you propose here.

 

[Andreas Leitgeb]

Iterable<Node> getChildrenIterable() {
return new Iterable<Node>() {
public Iterator<Node> iterator() {
return getChildrenIterator();
}
}
}

Yes, that would have been even better.

So you answered your question better than I did

 

[Mike Schilling]

There was a reason why they were added to the Java language.
Obviously somebody missed them.

No one's stepped up and said "I created one, even once". So your
argument is that we'd miss something we don't use.

 

[Mike Schilling]

I didn't realise we did have them! When were they added?

Long ago, at the same time as anonymous classes.

 

[Lew]

No one's stepped up and said "I created one, even once".  So your
argument is that we'd miss something we don't use.

Your logic is utterly fallacious. That is not my argument, and I'll
thank you not to put words in my mouth.

No one *in this newsgroup* has stepped up, so far. That proves only
that no one in a particular limited population has used them, yet.
Given that how many readers here are still learning what nested
classes even are, let alone local classes, and that the readership
here is not a comprehensive, random or representative sample of Java
programmers, that proves exactly absolutely nothing except that many
of us are still learning.

One respondent has already provided valid scenarios where local
classes would be useful, e.g., as a cleaner way of doing things than
with anonymous classes. This doesn't prove anything either, but it
does point to the possibility that somebody would miss them. Also,
now that we're discussing local classes, there's a good chance that
someone who heretofore didn't know of the feature, as another
respondent has already admitted, will begin to do so.

For the record, my argument is that someone did find local classes
useful, oh, twelve or so years ago, since the powers that be went
through the trouble to add the feature to Java. That is pretty strong
evidence that there was a use case for it, since an awful lot of
arguably useful features were not added to the language, yet that one
made the cut early on. Is your argument that it was added even though
no one felt a need for it? Or that they shouldn't have added it then
because no one in a small group attached to a particular news group
twelve years later would see the value, or even be aware of the
feature's existence?

I've also begun to see more value in the feature myself, now, and plan
to start to use it. A colleague of mine pointed out that the named
local class idiom is actually easier to read and more self-documenting
than the anonymous class idiom. His arguments are strong, if not
overwhelming, and given the rampant ignorance around inner classes in
Java generally, using such a thing to help readability is likely to
help maintainability of the code.

 

[Mike Schilling]

I use them a lot. I find anonymous inner classes break the flow of
the
code unless they are extremely short and simple. I prefer either a
static or non-static member class, with a meaningful name, depending
on whether the member class needs access to its surrounding class'
private data.

And you create local classes (defined within a method) for this?

 

[Mike Schilling]

Your logic is utterly fallacious. That is not my argument, and I'll
thank you not to put words in my mouth.

No one *in this newsgroup* has stepped up, so far. That proves only
that no one in a particular limited population has used them, yet.
Given that how many readers here are still learning what nested
classes even are, let alone local classes, and that the readership
here is not a comprehensive, random or representative sample of Java
programmers, that proves exactly absolutely nothing except that many
of us are still learning.

In all the Apache or other open-source code I've read, I've never even
seem one. Have you?

One respondent has already provided valid scenarios where local
classes would be useful, e.g., as a cleaner way of doing things than
with anonymous classes. This doesn't prove anything either, but it
does point to the possibility that somebody would miss them. Also,
now that we're discussing local classes, there's a good chance that
someone who heretofore didn't know of the feature, as another
respondent has already admitted, will begin to do so.

For the record, my argument is that someone did find local classes
useful, oh, twelve or so years ago, since the powers that be went
through the trouble to add the feature to Java.

They were added at the same time as inner and anonymous classes, very
possibly because it seemed like a logical intermediate step between
the two, or even because they fell naturally out of the
implementation. Since then, they've hardly been used.

That is pretty strong
evidence that there was a use case for it, since an awful lot of
arguably useful features were not added to the language, yet that
one
made the cut early on. Is your argument that it was added even
though
no one felt a need for it? Or that they shouldn't have added it
then
because no one in a small group attached to a particular news group
twelve years later would see the value, or even be aware of the
feature's existence?

I've also begun to see more value in the feature myself, now, and
plan
to start to use it. A colleague of mine pointed out that the named
local class idiom is actually easier to read and more
self-documenting
than the anonymous class idiom. His arguments are strong, if not
overwhelming, and given the rampant ignorance around inner classes
in
Java generally, using such a thing to help readability is likely to
help maintainability of the code.

If local classes didn't exist and you had to make these member
classes, would you think "Geez, if only I could limit their scope by
defining them within a method.?" Honestly, would you?

 

[Lew]

In all the Apache or other open-source code I've read, I've never even
seem one.   Have you?

Now, that is better logic.

They were added at the same time as inner and anonymous classes, very
possibly because it seemed like a logical intermediate step between
the two, or even because they fell naturally out of the
implementation.  Since then, they've hardly been used.
...
If local classes didn't exist and you had to make these member
classes, would you think "Geez, if only I could limit their scope by
defining them within a method.?"  Honestly, would you?

I might now, given that they have already existed and I've been made
aware of them. If they had never existed, conceivably I might have
trouble imagining them.

It is harder to imagine things that never were and ask, "Why not?"
than to look at things as they are and ask, "Why?"

That they have been rarely used is not a compelling argument against
them, although it is indicative. Many features of Java are either
under-utilized or only suitable for rare use cases. But when you are
in those rare use cases, it's awfully handy to have that rarely-used
feature.

Personally, I like anonymous classes. The argument for named local
classes to me is that they are a better-self-documenting idiom than
anonymous classes, and suitable any place you'd have a method-scoped
anonymous class. If that anonymous class were better served as a
member class, then a local class wouldn't be an option. If that
anonymous class serves better than a member class, then a named local
class is a viable option.

 

[markspace]

I've also begun to see more value in the feature myself, now, and plan
to start to use it. A colleague of mine pointed out that the named
local class idiom is actually easier to read and more self-documenting
than the anonymous class idiom.

I've used anonymous classes for test cases:

class Tester {

public void testIt() {

BigInterfaceClass testCase = new BigInterfaceClass() {
... lots of methods implemented here
};
... test cases using testCase...

}

}

This might be more clearer as a local class. It's something for me to
think about, at least.

 

[Mike Schilling]

Now, that is better logic.


I might now, given that they have already existed and I've been made
aware of them. If they had never existed, conceivably I might have
trouble imagining them.

It is harder to imagine things that never were and ask, "Why not?"
than to look at things as they are and ask, "Why?"

That's what I mean by "not missing them". There are a few places I'd
like to be able to scope things more closely [1], but allowing an
inner class to be used by only one method has never been one of them.
If it weren't possible, it would never occur to me to ask for it.

1. One example: sometimes I'd like to be able to declare that a
private field can only be seen by certain methods, e.g. to force the
use of an accessor even within the declaring class.

 

[Joshua Cranmer]

Speaking of which, a semi-tangential question: has anyone ever found
a use for a local class (i.e, a class defined inside a method, just
like an anonymous class, but given a name)? I never have.

I actually used it once, although I think I have since deleted that
code. I don't recall why I used it, but it was either something to do
about a constructor or a static method. This was back in the day,
though, when my knowledge of Java was a bit more limited.

 

[Tom Anderson]

February, 1997.

Oh, one of those new features, then.

Dammit.

tom