为什么 Iterable和迭代器在不同的包中？

发布于 2024-11-27 04:46:15 字数 544 浏览 0 评论 0原文

Iterable 位于 java.lang 中，而 Iterator 位于 java.util 中。这是否有充分的理由，或者这仅仅是糟糕设计的产物？

这看起来很奇怪，因为 Iterable 唯一有用的就是提供 Iterator。

编辑：一个潜在的原因是（当时）新引入的 for-each 循环。我想我的问题是，它们相等吗？

for(Object o : collection)
    ...
vs
for( Iterator iter = collection.iterator(); iter.hasNext(); ) {
    o = iter.next();
    ...

如果是，那么这仍然不能解释为什么这两个类位于不同的包中，因为编译器无论如何都必须导入 java.util 才能使用 Iterator 构造。

原文

Iterable<E> is in java.lang whereas Iterator<E> is in java.util. Is there a good reason for this or is this merely an artifact of bad design?

It seems strange since the only thing that an Iterable<E> is good for is providing an Iterator<E>.

EDIT: One potential reason is because of the (then-)newly introduced for-each loop. I guess my question then would be, are they equivalent?

for(Object o : collection)
    ...
vs
for( Iterator iter = collection.iterator(); iter.hasNext(); ) {
    o = iter.next();
    ...

If they are, then that still doesn't explain why the two classes are in different packages since the compiler would have to import java.util anyways to use the Iterator construct.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

时常饿 2024-12-04 04:46:16

其中一部分是历史：Iterator 自 JDK 1.2 以来一直伴随着我们，而 Iterable 则随 JDK 1.5 一起出现。 Iterable 伴随着增强的 for 循环而来。

设计不好？不，进化。没有全知的创造者。随着经验教训的积累，它们被合并到 JDK 中。

回复收藏 0 原文

伤感在游骋 2024-12-04 04:46:16

java.lang 是为语言功能依赖的类保留的。 Iterable 直接通过 for-each 循环提供语言级支持，但 Iterator 没有。

回复收藏 0 原文

绝影如岚 2024-12-04 04:46:16

大多数集合都实现了 Iterable，以便您可以使用方便的 for 循环语法：

Iterable<T> someIterableThing;
for (T x : someIterableThing) { ... }

我想 Iterable 位于 java.lang 中，因为它是与这种语法密切相关，这是 Java 语言的一个特性。

Most of the collections implement Iterable so that you can use the convenient for loop syntax:

Iterable<T> someIterableThing;
for (T x : someIterableThing) { ... }

I would imagine that Iterable is in java.lang because it's strongly related to this syntax, a feature of the Java language.

回复收藏 0 原文

黑色毁心梦 2024-12-04 04:46:16

随着时间的推移，Java 的 java.* 子包已经形成了各种循环依赖关系。例如，

java.lang.Process -- java.io
java.lang.Readable -- java.io、java.nio
java.lang.String -- java.util
java.lang.System -- java.io、java。 nio、java.util

所以我认为最好不要将子包视为清晰分层依赖关系的机制。相反，子包组相关的、专门的行为（除了包罗万象的 util）和 lang 有选择地引入一些非常有用的构造，例如 Iterator > 和区域设置。

我想人们也可以将这一切归结为熵。

回复收藏 0 原文

筱果果 2024-12-04 04:46:16

回答附加问题：

增强的 for 循环有两种变体。其中之一，当其中的 collection 参数

for(E o : collection) {
    ...
}

是实现 Iterable 的东西时，完全等同于

for (Iterator<E> iter = collection.iterator(); iter.hasNext(); ) {
    E o = iter.next();
    ...
}

（不同之处在于 Iterator 没有可以使用的变量名称）在循环的其余部分中访问）。编译器将为每个版本生成非常相似甚至完全相同的代码。

增强的 for 循环还有另一种变体：当 collection 是一个数组时，它会被编译成这样的东西：（

E[] a = collection;
for(int i = 0; i < a.length; i++) {
    E o = a[i];
    ...
}

当然，这里我们不能直接也可以访问 a 或 i。）

顺便说一句，编译器不会导入 java.util.Iterator - 在编译的字节码中，每种类型都以其全名来引用。（无论如何，局部变量并不是真正类型化的 - 其他一些 checkcast 断言。）

To answer the additional question:

The enhanced for loop has two variants. One of them, when the collection argument in

for(E o : collection) {
    ...
}

is something which implements Iterable<E>, is exactly equivalent to

for (Iterator<E> iter = collection.iterator(); iter.hasNext(); ) {
    E o = iter.next();
    ...
}

(with the difference that the Iterator has no variable name that you can access in the rest of the loop). The compiler will generate quite similar or even exactly the same code for each version.

There is another variant of the enhanced for loop: when the collection is an array, it will get compiled to something like this:

E[] a = collection;
for(int i = 0; i < a.length; i++) {
    E o = a[i];
    ...
}

(Of course, here we can't directly access a or i, too.)

By the way, the compiler does not import java.util.Iterator - in the compiled bytecode, each type is referred to by its full name. (And local variables are not really typed, anyway - other for some checkcast assertions.)

回复收藏 0 原文

~没有更多了~