>> 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.

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
>
>