Squeak and Namespaces

brad fowlow fowlow at pacbell.net
Thu Nov 30 09:17:25 UTC 2006


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061130/d519571c/attachment.htm


More information about the Squeak-dev mailing list