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
|