On Apr 1, 2004, at 3:23 PM, Andreas Raab wrote:

> Ah, but that isn't the point here. "Squeak::Object" describes the 
> "global
> class Object" whereas #Object describes "class Object in my local
> namespace". The trouble is that ClassBuilder isn't aware that #Object 
> has to
> be interpreted in the local namespace. The reason why this problem is
> interesting is that you may easily expect that someone would want to
> "override" the name of an existing class - which indeed is precisely 
> the
> point (I wanted to be able to provide a "clean" class hierarchy without
> having to resort to prefixing).

Right, after having looked at your code I realized that.  But

Squeak::Object subclass: #'Tweak::Object'
    ...

would work at least, right?

> "Implicit Imports" are VERY problematic in a dynamic system. It raises 
> all
> sorts of questions like "what happens if I import A and B and then 
> define
> A::Foo and B::Foo" etc. My take on this is basically that really you
> shouldn't do "implicit imports" but rather an import is an explicit 
> action
> which says importing A::* means (at the point where you "import" via a
> dedicated UI action) that you take all of the existing A::* entries 
> and put
> their short names into your environment. The "fileOut" version would 
> then
> look like:
>
> self import: A::Foo as: #Foo.
> self import: A::Bar as: #Bar.
> self import: A::Mumble as: #Mumble.

<snip>

Convinced, I think.  But namespaces are hierarchical, right?  So you 
can still reference objects in your parent namespace without qualifying 
them?  Since surely we won't be constantly using (Squeak::Array new: 
10), etc.

> Sent it in another mail already. Oh, and do you realize that the same
> "naming scheme" can be applied to selectors? Say having message 
> Foo::bar vs.
> Mumble::bar ;-)

Yup, I mentioned that earlier.  But since there's no equivalent to 
#bindingOf: for selectors, that's less immediately useful.

Avi