Have a look at ClassBoxes: http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf
I think they come pretty close to what you have in mind. On 2013-02-03, at 12:30, Denis Kudriashov <[email protected]> wrote: > Hello. > > Some days ago I think about how java works with dependencies and how it can > be implemented in smalltalk. > > 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. > > 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
