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.
Er... yuck.
Michael.