<div><div><div dir="auto">Yes, certainly those are all very interesting topics worth exploring. The idea of multiple images running in parallel, methods per namespace as in SmalltalkAgents, all that sounds wonderful to me. But they are also ambitious ideas that are unlikely to be realised in Cuis anytime soon, so I’m also interested in simple solutions to small problems. Of course I don’t want to discourage people exploring those great ideas, I’m very glad some people is thinking on that too.</div></div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 1 Jul 2020 at 4:45 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-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi Luciano,<br>
<br>
what I meant is that class name conflicts solving is, well, clearly a<br>
partial solution with downsides, such as explaining to another<br>
developer that in that browser on the right, Morph is not Morph that<br>
you see in the browser on the left.<br>
<br>
If you start to focus on the need, then interesting solutions start to<br>
show up, and those solutions solve more issues or allow new uses. Why<br>
not consider those? Versioning is one of those "interesting<br>
solutions"... what if we could version / fork / rollback / merge<br>
entire images contents?<br>
<br>
By the way, in a proper namespace "vision", I would consider proper<br>
that I can only use Domains extension to Number if I add Domains in my<br>
imported namespaces.<br>
<br>
Thierry<br>
<br>
Le mer. 1 juil. 2020 à 11:32, Luciano Notarfrancesco<br>
<<a href="mailto:luchiano@gmail.com" target="_blank">luchiano@gmail.com</a>> a écrit :<br>
><br>
> Hi Thierry,<br>
> 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).<br>
> 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>
><br>
> 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>
>><br>
>> 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>