> Folks -
>
> Since we are talking about name spaces (and packages (and how they are 
> or are not related)), I thought I would mention a point of view which 
> has helped me to understand such topics in the past.  I have found it 
> useful simply because, in the midst of many other  theoretical 
> considerations, this one is entirely pragmatic, and therefore somehow 
> easier to evaluate.
>
> Whatever the module, whether it is a namespace, or a package, or a 
> project (which I usually consider to be a combination of the two), or 
> even something like an ImageSegment, the first questions asked are:
>
> 	If you load a new module, how does it affect the rest of the system?
> 	If you remove a module, how does it affect the rest of the system?

I think that you have another one.

	If I change a module how many other modules do I have to change?

> When you put these together, it suggests a desideratum:
>
> 	If you load a module and then unload it, you should not be able to 
> tell it was ever loaded.

Yes this is why normally as a good citizen you have to clean the place. 
In Envy there was an unload hook, in parcel too. Then in parcel in 
VW3.0 there was an hidden namespace so that the
code your module could hide was put back in place as if your parcel was 
not loaded.

>
> This is often casts a fresh light on the nature of the interface 
> between each module and the rest of the system.  In the case of 
> packages, it strongly suggests that (unchanged) source code be browsed 
> from the package, rather than polluting the changes file.\

Exact. Alex did its own per classbox change management with also a 
bytecode loader.

>   In the case of projects, it calls out various issues in the handling 
> of Symbols and global variables.  And at the highest level of the user 
> model, it is meaningful as well.
>
> I don't have a slant on the current name space discussions.  Well, I 
> do, but I'm too busy, and I trust Andreas.  I just wanted to pass this 
> along as a possibly useful metric during the engineering process of 
> getting everything to work well.

Dan I think that goran's point is more about the fact that namespace 
interact with the other
artefacts that exist. And you see that when programming in VW, at the 
end people fixes some rules
such as put one namespace in a package, then always have one namespace 
per project.

Stef