Hi 2013/2/4 Martin Dias <[email protected]>
> 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. > I think It can be implemented with method wrappers and without impact on performance of methods which has not everrided versions. When you load code from package with method extensions you can put this methods in target class with method wrappers which know about classboxies logic. But rest system will continue working as usuall. Do you have links on CoExist? Best regards, Denis > > 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 > > > > > >
