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 at netvision.net.il>
To: <squeak-dev at 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