[Cuis-dev] The other way to do namespaces

[Luciano Notarfrancesco]

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.

On Wed, 1 Jul 2020 at 4:45 PM, Thierry Goubier <thierry.goubier at gmail.com>
wrote:

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