I arrived to almost the same problem some weeks ago, when I was thinking on how to have multiple versions of Fuel at the same time, so one can, for example, easily migrate her files to a newer version.
Fuel has lots of extension methods, so we need also multiple versions of the same extension method. Then, I arrived to ClassBoxes paper, from which I would like to extract and reproduce the experiment in a Pharo2.0 with Opal compiler. I guess Opal can simplify the implementation. There is also a paper about a prototype named CoExist, based on squeak. I didn't try it but apparently they only have a little performance degradation, because they used a modified vm. Martin On Sun, Feb 3, 2013 at 12:36 PM, Camillo Bruni <[email protected]> wrote: > 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 > >
