On 3 February 2013 15:42, Denis Kudriashov <[email protected]> wrote: > 2013/2/3 Frank Shearar <[email protected]> >> >> >> For java example libA.jar uses SharedClass.methodA and libB.jar uses >> >> SharedClass.methodB. But #methodA exists only in version deployed as >> >> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. >> >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are >> >> defined explicitly in their classpathes. So libA.jar knows nothing >> >> about >> >> libS-b.jar and v.v. And that's why your java programm can works at same >> >> time with libA.jar and libB.jar. They will use different versions of >> >> same >> >> class. >> >> No they won't, unless you have separate class loaders. What will >> happen is you will get one version of a class or another. > > > Of course to get my java example working you should load classes from libA > and libB by separated class loaders. > In pharo there is no way to make it work. And this is what I want to discuss > here.
But it's complicated and fragile to have separate classloaders, and a nightmare to debug. The Java people actively avoid this, for instance in JBoss installations. Take a look at Colin Putney's Environments work in Squeak 4.5. It provides a, well, environment in which you can load classes such that you can avoid the name clash problem. _Right now_ that's all it does, but it'll likely do more in the future. Gilad Bracha et al's work in Newspeak is the real way to go, I reckon. (Environments could be a first step in that direction.) Newspeak uses fully parameterised modules, which are first class entities. In fact they really are (stateless) classes. However, Newspeak supports inner classes. >> frank >> >> >> What it means in context of pharo? >> >> >> >> In pharo we have configurations which manage dependencies of projects. >> >> But >> >> you can't use at same time projectA and projectB which depend on >> >> different >> >> versions of projectS (when they both use same SharedClass from projectS >> >> like in java example). If you load projectA last you will get >> >> SharedClass >> >> with only methodA. If you load projectB last you will get SharedClass >> >> with >> >> only methodB. So projectA and projectB can't works correctly at same >> >> time. >> >> My example very simple. It includes just single class differencies. It >> >> can >> >> be more complicated and java world is good example for this. >> >> >> >> So my global question is how it can be solved in pharo? Do you have >> >> some >> >> plan for this? >> >> >> >> I can't remember something similar in pharo vision docs. But maybe what >> >> Stephane called "modules system" is exactly about this? I mean what >> >> Stephane always opposes in namespaces/environment discussions. And I >> >> think >> >> that this problem is ortogonal to namespaces/environments support. Do >> >> you >> >> agree? Do you know about such reseach in smalltalk? >> >> >> >> Little conclusion about such module system (if we can named it such >> >> way?) >> >> and what it is required from pharo: >> >> >> >> - ability to get in image different versions of same package. >> >> - separated class (global) dictionaries (multiple Smalltalk's) per >> >> package >> >> version. Maybe it can be named Module. So let's think about Module as >> >> unique Package+Version pair which contains all globals specific to this >> >> version and all dependent other Modules. >> >> - each Module knows it dependencies from other Modules, This >> >> information >> >> can be retreived from configuration. >> >> - each method and class should know from which project version (module) >> >> it >> >> was loaded. >> >> - inside any methods compiler should resolve class names based on >> >> Module >> >> dependencies information. Compiler should lookup actual class objects >> >> from >> >> module dependencies hierarchy. So no global Smalltak for compiler. But >> >> Smalltalk can be stay in system as default core Module. >> >> - If you want to use class which presents in two loaded versions of >> >> same >> >> package you should resolve conflict manually. Such action should add >> >> dependency to Module of your code. >> >> - Module can't have dependencies of two Modules of same package. It >> >> means >> >> that code of your project can use only version of some dependant class. >> >> I >> >> think it is essential restriction of Modules system. >> >> >> >> Main thing which Module system can get to us is ability to safelly load >> >> any >> >> versions of our projects and use it. It is not matter how old this >> >> code. >> >> System just loads old version of pharo core for example. Existed pharo >> >> core >> >> will continue works correctly. >> >> >> >> So what you think about it? >> >> >> >> Best regards, >> >> Denis >> > >> > >> >
