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.



Yes, that would break, and this is something I hadn't thought of. Thanks for
bringing it up. I guess the programmer would need to be aware of this and
design code accordingly.

This makes my claim about code running in exactly the same environment
false. Instead, the code just runs in a very similar environment.


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.



The interaction is the problem -- if a package and its dependencies stays
the same but its environment changes, the package may become buggy. It
depends on how the package interacts with and depends on its environment. In
practise I'm hoping that it won't be much of an issue. There should be a
core set of stable library packages that won't change much that packages can
rely on.

On another note, I've also just looked into classes in the VM's special
objects array. These classes cannot be modified without causing side-effects
in the rest of the VM, and you can't have multiple versions of them. I might
have to add the caveat that these classes can't be modified. (These classes
are: "Smalltalk specialObjectsArray select: [ :each | each isKindOf: Class
].")

Gulik.

-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070924/4debcbb9/attachment.htm