Not replying particularly to your post, I just had an idea about one of
the things that seems problematic about namespaces. I get the feeling
that it has some "impedence mismatch" with technology such as a debugger
and a workspace.

Why an impedence mismatch? because namespaces are about bringing two
different points of view (mappings of names to meanings) into the same
runtime. And a debugger is about looking at the runtime itself. A
concrete way to think about namespaces is by thinking about it as
textual rewriting, maybe a bit similar to a specialized C preprocessor.
What it does is go around and magically rename all classes to have an
"MC" style prefix, and then fix the references to the classes according
to some specification (of which namespace should be used where).

The impedence mismatch is that while the look up is changed
consistently, so that the semantics work, which is all that a deployment
technology cares about (multiple libraries), the debugger needs to show
you what is going on in the runtime, after the namespace transformation.
So if the debugger were to show you a modified source, with the properly
resolved names, the "this works in a namespace, but fails in the
debugger" kind of questions would be less problematic.

This requires the debugger and the other development tools to show
distinct views of source code, which would take some work.

Of course this doesn't at all address the ways in which namespaces
remove incentives for actual integration, it just makes the runtime a
little less confusing to deal with.

BTW, I found the "black plane" name hilarious... whether namespaces are
the kind of flexibility we need, I don't know.

Daniel

Marcus Denker <marcus at ira.uka.de> wrote:
> On Fri, Jul 25, 2003 at 01:04:18PM +0300, Daniel Vainsencher wrote:
> > What I mean by the last issue is that namespaces don't solve the
> > integration problem, they just make its pain less direct. Whether this
> > is more of a benefit than it is a liability I think is a tricky
> > question.
> > 
> Yes, you are right... but I think that the benefit could be greater,
> if such a system is used with care: e.g. it would be no good idea
> to ship the image with two versions of the library, and have parts of
> the image using the old one and parts the new one... this should be 
> used only for packages that build on top of the image and while
> migrating the image towards new version of a subsystem. 
> 
> The "perfect" approach to building new systems would be, I think, the  
> "burn the diskpacks" way: If you want to do something new, throw the old 
> stuff away and start from scratch, using all the knowledge you learned.
> 
> But this seems to me not very practical anymore: This was a great way
> for the 70ties, but the sytems we are building are too big for that
> today. Just take croquet: I don't think something like that would
> be possible to build that fast "from scratch". You need to have a
> good and proven basis, especially if you try to jump into the blue 
> plane... 
> 
> The same is true for the black-plane people (black plane: "doing things
> with squeak that were old even before squeak was invented" or: that
> stuff you need to do to get food on the table): Using Squeak as a 
> "free visualworks" requires a system that is somewhat stable in the
> sense "I can update and my stuff will be up and running again with
> not-too-much work".  
> 
> So, interestingly, both blue and black needs something to build upon.
> The problem is: This makes changing the system very difficult. 
> Even ignoring the "black plane": As soon as you have two groups doing
> blue plane stuff, you will have a clash: The blue-plane-part of the
> person will be the basis of the other... 
> 
> So to make real progress possible (esp. in the blue plane) we need
> a system that is stable *and* mealable. A big part of this is adding
> more late-binding to the system: Meta Object Protocols are a nice
> example for that. By providing a protocoll (API) for changing (or
> hooking into) the implementation of the system itself (e.g. changing
> method lookup), you can go very far in experimentation without hurting 
> others....
> 
>        Marcus 
> 
> -- 
> Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de