I think if we ever have selector name spaces and such (that produce the
capability I call "co-existance") there should be no link between the
name spaces, versions, and dependencies. 

To try and predict and specify in advance which versions of other
modules this module will work with seems to me very similar to declaring
variable types. I think it's the same sort of decision (I think I know
what kind object will come here..), with some of the same costs
(maintainance, cost of change rises, opportunities lost).

Anyway, Squeak is very far from being used as a typical OS, and maybe
never will. The real question is, does this technology, that will
require low level changes, and will require people to let go of some
important working assumptions(1), solve a problem we actually have,
right now? is that problem that big?

(1) example - "if the debugger stack says I'm in Bla>>blur, and I'm in
the Browser, looking at that method, and I haven't changed anything,
then I'm definitely looking at what was running when the error happened,
because that's all there is". Let go of enough such assumptions and you
bring the barrier of entry into coding in such a system high enough,
that your community will change in ways you might not like. 

Again, the tradeoffs for this decision are very different if you live in
a closed source world...

Daniel Vainsencher

Les Tyrrell <tyrrell at canis.uiuc.edu> wrote:
> 
> ----- 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