[ANN] Another namespaces approach.

Igor Stasenko siguctua at gmail.com
Mon Sep 24 07:14:06 UTC 2007


On 23 Sep 2007 14:32:40 +0200, Lex Spoon <lex at lexspoon.org> wrote:
> "Michael van der Gulik" <mikevdg at gmail.com> writes:
> > - Packages depends on other packages by UUID, and if you modify a package it
> > gets a new UUID. This means that your code will never suffer from dependency
> > problems and will always run in exactly the same environment you wrote and
> > tested it in. Bit-rot shouldn't happen unless you start changing the VM.
>
> All dependencies work this way?
>
> If so, then how do you handle situations where two packages depend on
> different versions of some third packages?  Let's make it concrete and
> say packages A and B both depend on package Morphic.  A creates a
> morph, hands it to B, and then B tries to add the morph to a window.
> How does this work?  Does B's Morphic really have to cope with a morph
> created by A's Morphic?  That would seem to mean Morphic has to be
> written very defensively, thus defeating the point of the exercise.
>

This is a decision which must be handled by developer. If i , lets
say, creating a package and adding imports to it, then dev tools
should warn me, that i have multiple versions of same package(s)
imported by mine.
There are two choices for developer:
- update imports of those packages, so they will use same version of
some base package. This is a good choice, btw, forcing developers to
sync versions of different packages and update code to work fine with
latest updates.
- second choice is to keep things intact, then it's a developer's
responsibility to write code in his package in such way, that there
will no conflicts occur, like using instances of classes, created by
package A, but thinking that these instances have behavior denoted in
package B.

> My gut is that loading multiple live versions should not be the
> default.  By default, packages are not supposed to hum along in their
> own private worlds, completely immune to anything else that is
> happening in the image.  Instead, packages are supposed to interact.
> They should interact with the user, with the image, and with each
> other.
>
> Yes, they should interact carefully, and they should avoid making too
> many assumptions about each other.  Still, interact they should.
>
> Now, as a non-default option, it's a different matter.  It would be
> cool to be able to create a sub-image that has its own versions of
> packages in it....
>
> Lex
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list