goran.krampe at bluefish.se wrote on 06.04.2004 16:53:31:

>Calling the namespaces "meaningless" is a bit harsh I think. Also - I 
>am not as certain as you are that people will refrain from giving 
>things descriptive names.

No, it is not harsh. The namespace information will give you no 
immediate clue about what hides behind a name. It is easy to confuse 
useful info with pseudo info, and that's exactly the danger. I guess 
programmers of other languages are even proud of their namespace 
monsters. 
 
>> Yes, but I just wanted to repeat your warnings about what will 
>> "crash down the hill on us". Your idea of having many small 
>> namespaces in the Full image showed me, how fast one can become 
>> intrigued by the "coolness" of namespaces. ( Starting out critical 
>> and then becoming converted without recognizing it. Well, not 
>> really ;-) 
>
>Eh... you lost me. "Many small namespaces in the Full image?" I assume
>you are talking about the "many small packages"? I still think that 
>is a good idea, at least much smaller than the current image.

You said: 
So typically we have say these Namespaces (which I will use in the 
rest of the post as examples) and many more:
 Kernel
 Collections
 SqueakMap
 Seaside

>> My gut feeling was and is that the official Full image should be 
>> only one single namespace. Of course the question then arises, what 
>> the goal of such namespaces is. And surely this will have some 
>> drawbacks, 
>
>I am not sure I disagree with that. I mean - that is what it is today.
>But I still want to chop it up into well separated *packages* that can
>have their own releases cycles etc. As Andreas says - those things
>aren't one-to-one.

I am not sure either. But the problem is not to chop up the image into 
packages that live in one namespace. This construction of namespaces  
( one for Full and one for every SM package not in Full ) will enable 
loading together arbitrary SM packages into Full for a specific image! 
We can even integrate (i.e. add and make a new Full ) single existing 
SM packages to Full without name clashes. 

The problem will be only to integrate-add to Full packages from SM 
which are conflicting without their shielding namespace ( everyone who 
wants his package potentially being integrated in Full has to take 
care of name clashes with Full - as it is today ). And some other more 
ambitious things will not work at all. 

So in short, the main intention of SM would be fully delivered by this 
"restrictive" namespace policy and your proposal. But, as I said, I am 
not sure what weighs more, potential problems or potential chances. 
Sure I am regarding the problem of replacing meaningful with 
meaningless info. Many people are underestimating this problem, or 
they are not aware of it at all. 

regards, Martin