<br><br><div><span class="gmail_quote">On 2/24/07, <b class="gmail_sendername">J J</b> <<a href="mailto:azreal1977@hotmail.com">azreal1977@hotmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>>Usually though you'd just use:<br>><br>>a := Array new: 5.<br>><br>>and add the Collections.Arrayed Namespace to your import list. Each import<br>>list is common to all classes at a certain branch of the Namespace
<br>>hierarchy, so the dotted notation is only useful if, in the same branch of<br>>the Namespace hierarchy, you want to use two classes (or global vars) that<br>>have the same name.<br><br>When you say "global vars" you mean classes right?
</blockquote><div><br>I'll answer this question in more detail below...</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">And how does the import work? This is one thing I am concerned about: In
<br>python, your "unit of work" is a file. So you look at the top and see the<br>imports and you know they are valid for *this file" (or if you import in a<br>local scope it extends to the end of that scope). In smalltalk the compiled
<br>"unit of work" is a method, no? My import/export list is going to have to<br>be in the class definition right?</blockquote><div><br>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.
<br><br>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.<br><br>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. <br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I know these are things that can be overcome with the tools (maybe show the<br>
fully qualified class on mouseover), but it is just something to think<br>about. Oh, and if a base class imports a bunch of stuff does a derived<br>class get it too, or do I have to specify the same imports over and over? I
<br>suppose you could have a default import (e.g. Core.*), package imports and<br>class imports.</blockquote><div><br>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.
<br><br>There are no default imports or class imports. There's also no such thing as a package in my schema.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>I'm not entirely sure how I'd implement your message sending idea, and it<br>>doesn't particularly feel "right" to me. I assume you mean:<br>><br>>a := Collections Arrayed Array new: 5.<br>
><br>>Michael.<br><br>No, actually my favorite so far was from (I believe) Gemstone. As I recall,<br>it was something like:<br><br>((Collections at: #Arrayed) at: #Array) new: 5.</blockquote><div> </div></div>Er... yuck.
<br><br>Michael.<br>