On Nov 30, 2006, at 12:45 AM, Göran Krampe wrote:


It means that I can load 34 other packages into my image and as long as we

don't have *namespace name* clashes (like two people using the same name

for their namespace) nothing funky will happen in my source. All

references are still perfectly correct.


The only diff is that when I *browse* the code that earlier said

"Dictionary" now may say "Kernel::Dictionary" because my image now also

contains "Joes::Dictionar" and "Schmoes::Dictionary".



There's one thing I'm not clear on from the writeups is how legacy and namespaced code
are meant to interact in this proposal, in the phase were it is being introduced.  
Apologies if this has been covered, its been a long thread.

Sample scenario

I take a clean 3.9-ish image.
I load the namespace support.
I load a package that introduces the classes Someones::SharedQueue  and Someones::Something
<would that work, given that there is a naked SharedQueue in the system?>

I go into a method in Someones::Something and type
SharedQueue new.

Does this prompt a disambiguation question,
and if so, how do I indicate that I want to use the system's SharedQueue?

The answer earlier about how yes, one could use existing categories as defaults,
but you'd do it in the class-creation template, prompted this question.
What is the default full name of an existing class, 
when your changes are first incorporated into an image?

I.e. where did 'Kernel' come from in your example above,
if not by automatically namespacing legacy code by category?
And if that is done, does it immediately affect the content of all fileouts
and package commits?

Or is it the case that you can't introduce a namespace-prefixed name
whose base name is also present as a naked legacy class name?

-b