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".
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. Still, you've given me an idea. If java never gets closures, then java really is dead*. Not because closures are a panacea, but, for an entirely different reason: The majority of the community wants them. If java never delivers something that everyone wants, it's dead. Simple. Doesn't matter what the feature being asked for is. As long as the feature is reasonably well defined and there's a way to get there without too much collateral damage, java should get there if the community has made up its mind. It's okay if this takes careful deliberation and years of design considerations, but if it does happen within a reasonable time-span after community consensus, java is dead**. *) Assumptions: 1. The community is convinced closures are a good idea (which at java events seems to be sort of true, but that's not the ENTIRE community, just the most active members, though their say certainly should count more. The internet is a meritocracy, not a democracy, because the meritocracy model is more efficient, the internet is ruthless competition, and going against this grain will eventually get you killed. 2. At some point the community starts focusing on a single closure proposal, which might simply mean that the focus shifts a little from 'What's the best closure proposal' to 'which one(s) are good enough for you?' If those assumptions don't pan out, then java not getting closures is no cause to say java is dead. **) 'dead' in the sense that cobol is dead. Due to java's legacy, we'll have java code running critical systems and a few old farts earning a pretty penny keeping them running for a very long time indeed, but we all have our gut instincts regarding languages like cobol, ada, pl/1, fortan, etcetera. When I say those languages are 'dead', I mean: They don't get taught at universities and you'd be laughed out of the room for suggesting it there, no one is offering courses, and nobody is lining up to learn them autodidactically either. No new projects are being written in them, and deployments are ever going down, never going up. NB: Viktor - a key difference between many of the extension point proposals is where you are allowed to declare the extension. In many proposals, you use a variant of static import (something like: import static Collections.sort into List), but now we either need to configure our IDEs to add a busload of static import statements on every source file, which can't be the right answer, or we need a 'read this file, and import everything IT imports' kind of system, or we need a module-level import system. Other proposals allow the target type to declare its own extensions, which doesn't allow you to 'hack' existing code, but it does allow existing code, particularly interfaces, to add new stuff without breaking backwards compatibility, and to add functionality on interfaces which doesn't usually change between implementations thereof, such as most of the stuff in java.util.Collections and java.util.Arrays. There are advantages and disadvantages to each, and you could even combine the proposals quite easily. On Feb 24, 5:06 am, Alex Buckley <alex.buck...@sun.com> wrote: > On Feb 23, 7:33 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: > > > I don't think you can just evolve incompatible APIs because you have a > > module system, Alex. > > What is the point of versioning in a module system if not to allow > multiple INcompatible versions to co-exist? (That doesn't require > every upgrade to introduce an incompatibility, only that a versioning > scheme describes when and how compatibility can be affected.) > > > Let's say we add a 'filter' method to list. How? We can only change > > List if we add List to the versioned set. But if we do that, then any > > two modules that require different versions can no longer talk to each > > other if the talk protocol involves Lists, which are almost as 'near- > > primitive' as Strings. That's not going to fly. You still need a way > > for an old 'view' on Lists, or for two separate List libraries to be > > able to hand each other wrappers or some other solution to cross this > > bridge. > > Of course java.util.List is in a versioned module. Every piece of code > you ever write is versioned, whether you write down the version or > not. Two modules that require disjoint versions of List cannot pass > Lists between themselves, but that is likely to be rare. What is far > more likely for core JDK classes is that we will promise to evolve > them in a way that is a) binary-compatible, b) behavior-compatible, > and c) not source-compatible. In other words, we will add methods to > List but (probably) not redefine existing methods. Again, this is what > a versioning scheme is for. Putting it all together, a module which > requires version >=7 of List and a module which requires version >=8 > of List (since the module uses List.filter) can both get version 9 of > List and cooperate at runtime. > > > Or you use extension methods and you don't have this problem. > > > NB: If you want a full proposal, it's very simple: > > Few things in the Java language are as simple as they seem. > > 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
