On 2/24/07, J J <azreal1977@hotmail.com> wrote:

>Usually though you'd just use:
>
>a := Array new: 5.
>
>and add the Collections.Arrayed Namespace to your import list. Each import
>list is common to all classes at a certain branch of the Namespace
>hierarchy, so the dotted notation is only useful if, in the same branch of
>the Namespace hierarchy, you want to use two classes (or global vars) that
>have the same name.

When you say "global vars" you mean classes right?

I'll answer this question in more detail below...

And how does the import work?  This is one thing I am concerned about:  In
python, your "unit of work" is a file.  So you look at the top and see the
imports and you know they are valid for *this file" (or if you import in a
local scope it extends to the end of that scope).  In smalltalk the compiled
"unit of work" is a method, no?  My import/export list is going to have to
be in the class definition right?

No - I've designed it so that the import list is part of the current local Namespace and is shared by all classes at that level of nesting in that Namespace. Note that this design isn't final; I'm going to see what pragmatically works best.

A Namespace is a Dictionary and has a list of imports. It maps #Names to objects, and those objects would be predominantly classes but could be any object in the current image.

When your code is compiled, I've changed it so that it searches for global variables first directly in that classes' namespace, and then in that namespace's import list. If the name uses the dot notation ( e.g. #'Collections.OrderedCollection') then it splits the name up first before searching.

An example: for #'Collections.OrderedCollection', it would first search for #Collections in the local Namespace for the class you're working with. If it isn't there, it then searches in the import list of that Namespace. When it finds #Collections (which would be another Namespace) in the import list, it then looks up #OrderedCollection within the #Collections Namespace.

I know these are things that can be overcome with the tools (maybe show the
fully qualified class on mouseover), but it is just something to think
about. Oh, and if a base class imports a bunch of stuff does a derived
class get it too, or do I have to specify the same imports over and over? I
suppose you could have a default import (e.g. Core.*), package imports and
class imports.

Erm... read the above. The imports of a base class have no effect on the imports of any subclasses. If they're in the same Namespace, they have the same import list. If they aren't, then they don't.

There are no default imports or class imports. There's also no such thing as a package in my schema.

>I'm not entirely sure how I'd implement your message sending idea, and it
>doesn't particularly feel "right" to me. I assume you mean:
>
>a := Collections Arrayed Array new: 5.
>
>Michael.

No, actually my favorite so far was from (I believe) Gemstone. As I recall,
it was something like:

((Collections at: #Arrayed) at: #Array) new: 5.