<div dir="ltr"><div dir="ltr"><div><div dir="auto">Hi Thierry,</div><div dir="auto">I think creating subclasses on the fly doesn’t really solve the problem of packages modifying existing classes, because these modifications are not expected to be limited to objects instantiated by methods inside the package. For example imagine a package adding functionality to Number, Integer, etc (as my Domains package). Or a package changing existing methods in Class and SystemDictionary (as the System-Namespaces and System-Environments packages).</div><div>It's the infamous "slippery slope", I guess. Now we're talking about versioning and about multiple images. It's all very interesting, but personally I would be happy if we just solved the problem of class name collisions between packages.<br></div></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 1 Jul 2020 at 4:15 PM, Thierry Goubier <<a href="mailto:thierry.goubier@gmail.com" target="_blank">thierry.goubier@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Luciano,<br>
<br>
Le mer. 1 juil. 2020 à 10:56, Luciano Notarfrancesco via Cuis-dev<br>
<<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> a écrit :<br>
><br>
> On Tue, Jun 30, 2020 at 11:11 PM <<a href="mailto:ken.dickey@whidbey.com" target="_blank">ken.dickey@whidbey.com</a>> wrote:<br>
>><br>
>> Also, I am interested in being able to have<br>
>> multiple versions of a single Feature/Package which I can easily do with<br>
>> Environments.<br>
><br>
><br>
> Just want to point out that packages include not only newly defined classes but also changes to classes in the base system or other packages (new methods or modifications to existing methods).<br>
<br>
I would say "may include"<br>
<br>
A complete solution to multiple packages loading in an image while<br>
guaranteeing no conflict seems doable, but a tad complex (for example,<br>
creating on the fly subclasses of base image classes only visible<br>
inside the package namespace -- I don't want to have to explain that<br>
to students :( ).<br>
<br>
To compare with: connecting as one multiple images (processes) with<br>
each containing one such package.<br>
<br>
The second one would allow scaling to hundreds or thousands of CPUs /<br>
core, if needed. Aka better than the ROAR VM, in my opinion, which<br>
rely on shared memory to distribute (but one could use a DSM, like the<br>
one we are using in my lab... well, S-DSM really).<br>
<br>
Thierry<br>
<br>
> --<br>
> Cuis-dev mailing list<br>
> <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>
</div>