On 3 February 2013 20:42, Igor Stasenko <[email protected]> wrote: > On 3 February 2013 20:53, Miguel Moquillon <[email protected]> wrote: >> Le 03/02/2013 19:27, Denis Kudriashov a écrit : >>> 2013/2/3 Miguel Moquillon <[email protected] >>> <mailto:[email protected]>> >> >>> >>> And the Java people are preparing to throw away the classloaders >>> mechanism with Jigsaw that will be in Java 9. (The classloading is a >>> brittle and error-prone mechanism.) The aim of jigswa is to design >>> and implement a new module system for the Java SE platform and to >>> apply that system to the platform itself and to the JDK (more >>> information in the project homepage >>> http://openjdk.java.net/projects/jigsaw/ >>> <http://openjdk.java.net/projects/jigsaw/>). >> >>> >>> Miguel >>> >>> >>> I know about this. But let's talk about pharo. Now pharo can't do >>> this. You can't have two versions of same package at same time in >>> image. So how we can implement it? And do this is really important? >> >> >> IMHO, it is not important and should be avoided because it is error-prone >> (what is the actual version used by the objects?). This can even be a >> nightmare with a lot of dependencies when an error occurs. >> Don't forget: keep things simple (it is always more easily to build too more >> complex systems). >> Having a program depending on a package in two different versions at the >> same time in an image is in my opinion a design error. And if your program >> depends on some tiers-party packages that depend on a different version of a >> same package, then you should decide for the more recent one (or according >> to other heuristic) and fix, if needed, the dependency in the others >> packages. This is more easy to do with Pharo than with Java. >> Even in Java, we take care to avoid these situations by using a dependency >> exclusion with Maven. >> > > +1. From a first sight, it looks like we are missing features to > support such cases (like having two > different versions of same class because of dependencies), but if we > look at results of having this, > it is apparent that it will serve as a source of confusion, and while > in perfect cases this will work fine, > i would hate knowing that my project, in order to function properly, > requires two different versions > of same class (or package) and avoid this at all costs.
It's a nice idea, to avoid this kind of situation at all costs. The problem is, you can't. > I think this problem stems from having a proprietary code, which you > cannot control or change, > but since in pharo we don't have such 'frozen & closed' code, all the > problems with dependencies > can be solved in more traditional manner: by fixing them :) Well, no, unless you write all your libraries yourself. Noone, especially not people trying to deliver software in a commercial context, can afford to write everything themselves. You'll have to use other people's libraries. Now sure, you can talk to the library authors, and encourage them to all use the same version of Foo or whatever, but it's not actually something you can avoid "at all costs". So we might as well think about how to actually deal with the problem. frank >> Miguel >> > > > > -- > Best regards, > Igor Stasenko. >
