----- Original Message -----
From: "Colin Putney" <cputney at whistler.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, October 31, 2002 1:38 AM
Subject: Re: An uncomfortable question


>
> Daniel Joyce wrote the following in reference to Dean Swan's post :
>
> > He's implying we'll end up with the equivalent of DLL Hell that Windows
> > ( and to a lesser extent ) windows have.
> >
> > Linux survives in the fact that diff versions of the same libs can live
> > together happily by using symbolic links, and ld. Simple, and works
> > better than windows registry pain....
> >
> > Modules MUST support version dependency, and different versions of the
> > same modules living on the host system if this is to work...
>
> I agree that packages should be versioned, and that dependencies should
> include version information. But I also think that having multiple
> versions of a package installed in a single image would not be a good
> idea. The benefits are not worth the complexity it would require.


It is a bit early to state it that emphatically.  There is no evidence to
support the notion that having this ability would be any more complex in
practice than not having it, as we do now.  You are used to the situation we
have now... so you think of it as being "simple", by virtue of familiarity.
As long as we arbitrarily ignore the vast amounts of code which are *not*
routinely packaged in the official release, then certainly we can "simplify"
the problem.  However, if you now want to consider what it takes to use all
those other bits of code, then we find that there is a fair bit of missing
tool support to make this job easier.   Deliberately choosing to neither
develop nor use such tools does not "simplify" life.


> Consider that images are not the same as operating systems. Linux can
> have multiple versions of a library installed and allow different
> executables to link against the versions they require. But you can't
> have two different versions of a library linked into the same process
> space. The Squeak parallel would be to have multiple versions of a
> package available on SqueakMap and have different versions installed in
> different images.


Or provide the means to support multiple versions in the image simultaneously.
Nontrivial, but feasible and already largely demonstrated in Oasis.  But at a
higher level I'd reccomend that we consider that OS's do a lot of things much
better than what we are doing "within" the image right now.  It is worth
considering ( as I believe Stephen Pair once suggested ) a comparison and
contrast between Squeak/Smalltalk/image and OS/file systems.  To wit: in an
OS, having something be *available* to use  is not the same thing as
*demanding* that it already be in memory.    And when done using that thing,
it goes away.  Compare that to the way in which we currently manage our
images.   There is a big realm of transient things that are not managed at
all- we load them at some point, and from that point on, they stay in the
image, because we do not have tools to identify the extent of these things and
what is needed to remove them.  I just don't see how deliberately deciding to
never develop such tools will ever be a good thing.


> Now consider the complexity supporting this would introduce to Squeak.
> The VM would have to take dependencies into account during method
> lookups. You'd have to have separate namespaces for globals. The
> Browser would have to present multiple versions of methods to the user,
> the Compiler would have to store compiled methods in the right
> namespace etc. That's all possible of course, but it's a low-level,
> far-reaching change with deep implications.


The specifics are not exactly what I'd anticipate, but the gist I agree with-
very deep impact at a low level, decidedly non-trivial.  However, technically
feasible-  a big chunk of this is already working rather well in Oasis.


> And then there's the complexity cost at the user/developer level. Can
> you imaging debugging in an image where there are different versions of
> the same method floating around and the version that actually gets
> execcuted depends on the class of the sender? Dear God!


Having method lookup based partially on the sender is actually vital and
neccessary if this is all going to work coherently... the easiest way to
understand this is to ask yourself, "when travelling overseas or in another
country, do I continue to behave according to my own culture's beliefs and
values, or do I adopt the behaviors of the country I'm visiting?"   Things go
a lot easier when you do your best to respect and blend in with the local
customs.  In our Smalltalk world, this means that objects crossing domain ( or
module or whatever ) boundaries need to behave according to the local customs
( ie, methods which may have been provided/altered for them by the
module/domain they are visiting ) of the domain that they are visiting.   This
makes it trivial to reason about the behavior of say, OrderedCollection, when
instances are zooming through Module X or Module Y, where X & Y provide
differing behavior for OrderedCollections.  Also perhaps non-trivial, but I
believe that Stephen Pair has some form of selector namespaces already
working.

Take care,

- les