On 2/24/07, J J <azreal1977 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070301/2612a0b1/attachment.htm