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@canis.uiuc.edu wrote:
----- Original Message ----- From: "Colin Putney" cputney@whistler.com To: squeak-dev@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
I don't buy that as a valid argument- the same thing could have been said in response to the notion of having classes contain subroutines. "If I am in the debugger looking at subroutine blah(); how can I know which blah() I'm looking at?". I don't think the solution to that problem turned out to be all that bad, and I don't think it matters whether you are dealing with closed or open source.
- les
----- Original Message ----- From: danielv@netvision.net.il To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, October 31, 2002 11:49 AM Subject: Re: An uncomfortable question
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
squeak-dev@lists.squeakfoundation.org