Right, so you agree that there are situations where a module must ask specifically for List[1..7] and cannot just go for [1..*]. I contend that these situations are sufficiently common that there's going to be a LOT of headache with incompatible modules, if this happens.
You also won't get any errors when you start implementing list when you compile this with java7, which is presumably the state of the art when the library is written. In other words, we have the following fun situation: A tonne of libraries out there will all of a sudden break when the new java8 (or whatever) is released with new methods on java.util.List, because they mistakenly specified compatibility with 7+. There's no way to test for this, certainly not at first (at some point I expect findbugs and other tools can find likely problems in this area). Also known as a clustersomething. Can't be done. > Alex Buckley said: "One paragraph does not a rant make" When you're attacking a strawman with hyperbole terms, then, yes, it was a rant. On Feb 24, 6:08 pm, Alex Buckley <[email protected]> wrote: > On Feb 24, 6:15 am, Reinier Zwitserloot <[email protected]> wrote: > > > Nope, if you want version 7 of List, you can't even use version 9 of > > List, because version 9 of List declares 'filter', which you can't > > work with. The module system does not,as far as I can tell, allow you > > to make the distinction: "I'm just using these" and "I'm extending > > list, and therefore you can't give me version 9, or there's a runtime > > error when I don't have my filter method". > > Again, where is your evidence for these statements? Let me inject some > reality: > > - A module which asks for version >=7 of List because it uses (but > does not extend) List can work with version 9, no problem. The > presence of additional List methods makes no difference. > > - A module which asks for version >=7 of List and extends List cannot > work with version 9 because adding methods to an interface is source- > incompatible. (The usual javac error will result when compiling the > extension of List.) A module containing a type that extends List > should ask for version 7.* of List, since source-incompatible changes > should not be made under the same major version (7). > > Therefore, the module system can discriminate between "safe" use > (references to List) and slightly more "dangerous" reuse (subclassing/ > subtyping). > > > Your rant on closures being seen as the key to the life of java: Who > > here in this thread has claimed that java is going to die without > > closures, and is going to be the best of the best with them? You're > > arguing against a straw man. > > One paragraph does not a rant make. The gist of many discussions on > "closures" is that "everyone" wants them and that Java is dead without > them because people will flock to Fan/Groovy/Scala/Ruby. I am an > enormous fan of Scala, but I recognize that Java and Scala have > complementary, not competing, roles. I look forward post-JDK7 to > better interoperation of the statically typed JVM languages; perhaps > that will come for free if the dynamic typing guys agree on a MOP. > > Alex --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
