On Mon, Feb 4, 2013 at 5:25 PM, Denis Kudriashov <[email protected]> wrote: > 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?
yes: http://www.bastiansteinert.org/coexist.html anyway it's a bit off-topic because their prototype is not about modules... best regards, Martin > > 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 >> > >> > >> >
