[Cuis-dev] The other way to do namespaces

[Thierry Goubier]

Hi Luciano,

what I meant is that class name conflicts solving is, well, clearly a
partial solution with downsides, such as explaining to another
developer that in that browser on the right, Morph is not Morph that
you see in the browser on the left.

If you start to focus on the need, then interesting solutions start to
show up, and those solutions solve more issues or allow new uses. Why
not consider those? Versioning is one of those "interesting
solutions"... what if we could version / fork / rollback / merge
entire images contents?

By the way, in a proper namespace "vision", I would consider proper
that I can only use Domains extension to Number if I add Domains in my
imported namespaces.

Thierry

Le mer. 1 juil. 2020 à 11:32, Luciano Notarfrancesco
<luchiano at gmail.com> a écrit :
>
> Hi Thierry,
> 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).
> 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.
>
> On Wed, 1 Jul 2020 at 4:15 PM, Thierry Goubier <thierry.goubier at gmail.com> wrote:
>>
>> Hi Luciano,
>>
>> Le mer. 1 juil. 2020 à 10:56, Luciano Notarfrancesco via Cuis-dev
>> <cuis-dev at lists.cuis.st> a écrit :
>> >
>> > On Tue, Jun 30, 2020 at 11:11 PM <ken.dickey at whidbey.com> wrote:
>> >>
>> >> Also, I am interested in being able to have
>> >> multiple versions of a single Feature/Package which I can easily do with
>> >> Environments.
>> >
>> >
>> > 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).
>>
>> I would say "may include"
>>
>> A complete solution to multiple packages loading in an image while
>> guaranteeing no conflict seems doable, but a tad complex (for example,
>> creating on the fly subclasses of base image classes only visible
>> inside the package namespace -- I don't want to have to explain that
>> to students :( ).
>>
>> To compare with: connecting as one multiple images (processes) with
>> each containing one such package.
>>
>> The second one would allow scaling to hundreds or thousands of CPUs /
>> core, if needed. Aka better than the ROAR VM, in my opinion, which
>> rely on shared memory to distribute (but one could use a DSM, like the
>> one we are using in my lab... well, S-DSM really).
>>
>> Thierry
>>
>> > --
>> > Cuis-dev mailing list
>> > Cuis-dev at lists.cuis.st
>> > https://lists.cuis.st/mailman/listinfo/cuis-dev