Timeline for Packaging structure of Java collections (java.util) - why does Iterable sit in java.lang?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 17, 2017 at 21:51 | vote | accept | overexchange | ||
| S Jun 20, 2015 at 12:39 | history | suggested | Peter Mortensen | CC BY-SA 3.0 |
Copy edited.
|
| Jun 20, 2015 at 12:38 | review | Suggested edits | |||
| S Jun 20, 2015 at 12:39 | |||||
| Jun 20, 2015 at 12:38 | comment | added | gnat | @ruakh I see. That's a very good point, thanks. I can understand why API designers wanted Iterable to expose "an object that performs iteration" but the way they have chosen to do this doesn't feel elegant | |
| Jun 20, 2015 at 10:31 | comment | added | ruakh |
My point was not that it's convenient, but that the language proper now depends on it. (Note that, aside from the dependency of Iterable on Iterator , the java.lang package does not generally depend on classes in java.util.)
|
|
| Jun 20, 2015 at 9:48 | comment | added | gnat | @ruakh Iterator is convenient, but was probably considered too specific (method selection and naming) to go to "fundamental" package. Think of its predecessor Enumeration, which eventually turned out not as convenient as originally thought, it was prudent that it didn't go to lang package | |
| Jun 20, 2015 at 9:34 | comment | added | ruakh |
+1. I think, though, that Iterator should ideally also be in java.lang, since Iterable is. Of course, it has to be in java.util for backward-compatibility reasons (it had been introduced in the JDK long before the "foreach" construct gave it a role in the language proper).
|
|
| Jun 20, 2015 at 2:17 | history | answered | gnat | CC BY-SA 3.0 |