Hi Lex!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> > > One thing that bothers me is the idea that a class will only be
> > > interested in a single namespace.  If I write some code, it seems that I
> > 
> > No, you are misinterpreting the class creation template as if it was an
> > "import". It is not.
> > The class *resides* in a single namespace. It has no imports so it has
> > no notion of "interest".
> 
> FYI, at this point I have no idea what you are proposing.

:) Sorry. My attempted explanations aren't helping I assume!

> These are
> just words and it doesn't help me to say they are wrong. " Reside"
> versus "import" versus "interest" does not help clear things up.  I
> would think that where you choose to reside is part of an expression of
> interest, and that on a computer, importing and referencing and indeed
> "residing" in a location are all mostly the same.

Ok, let me try to explain "a little bit" at least - this is all based on
my proposal and I have actually executed these expressions in an image:

A class resides in ONE and only one Namespace. This all means the
following in an image with my proposal loaded and the conversion having
been run:

"The class still hangs in Smalltalk and its name is #Network::Socket "
(Smalltalk at: #Network::Socket) == Network::Socket
	--> true

"The Namespace instance also hangs in Smalltalk and it's name is
#Network
The Namespace acts like an IdentityDictionary - even though it isn't
one, it just asks Smalltalk"
(Network at: #Socket) == Network::Socket
	--> true

"The name instvar of the class is just as expected"
Network::Socket name == #Network::Socket
	--> true

...so from this POV we have only simply made the names longer! Nothing
different. Very much like a formalized way of using prefixes. All
classes still hang in Smalltalk, they are still categorized as before in
SystemOrganization etc. 

Given these longer names classes (and other globals) will be harder to
write and read. Thus, we add a few rules for when the shorter name can
be used instead. The current (in my code) rules are:

1. If the name is in the same namespace as the class itself is in. So if
code in Tweak::Button refers to Tweak::Window then you can simply type
"Window" and also read it as "Window".

2. If not, then the name can *still* be rendered and entered in its
short form *if the short name is still unique in the image*.


> I guess I will wait on another summary writeup, or I will load your code
> and play with it.  I'd love to try and help out here, because this is an
> issue that can either make Squeak a lot better or a lot worse.  But I'm
> adrift now.

Currently the simplest way is to simple install it from SM and play with
it.
In an image of less affection value of course. :) There are class
comments for Namespace and LookupContext and you can also examine the
Changeset to see all modifications done so far.

Also note that you don't need to run the conversion script (Namespace
class>>reorganizeEverything) to play with it. It was just included to
show that we *can* partition stuff into Namespaces. Note also the
following:

1. Not all classes are moved to Namespaces. The categories mentioned in
#kernelCategories are excepted.

2. After the reorg things turn "flaky". There are obviously a bunch of
places in the image where the names are important. For example, I think
Morphic checks for its own existence by looking for #Morph in Smalltalk
or something, haven't investigated it.


> > > may very well want to import from both Tweak and from
> > > RegularExpressions.  Why should I have to pick which short names my code
> > > will be allowed to use?
> > 
> > You aren't picking, see above. :)
> 
> Either it "lives" in Tweak or it lives in RegularExpressions, right?  I
> type it in one way or I type it in the other.  How is this not "picking"
> ?

I agree - it lives in one of them. BUT... as longs as the unqualified
class names are unique in the image they will *still* be shown in the
short form! My current implementation ONLY uses the longer form when
there is an ambiguity.

> > Yes, IMHO this is almost *exclusively* about end user aspects. Names in
> > themselves are for *us* not the Compiler.
> 
> In fact, these items are not even in conflict.  Compilers are for end
> users, too: they translate between human languages and computer
> languages.  Some circles in fact call them translators, which is a much
> better name.

Sure, but the Compiler would be quite happy to just have UUIDs in the
code. :)
And I - as a human - wouldn't.

regards, Göran