[Cuis-dev] The other way to do namespaces

[Luciano Notarfrancesco]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200701/2f8ce48b/attachment.htm>