Namespaces (was: Re: [ANN]A plan for 3.8/4.0... (insertdrumroll
avi at beta4.com
Thu Apr 1 23:46:33 UTC 2004
On Apr 1, 2004, at 3:23 PM, Andreas Raab wrote:
> Ah, but that isn't the point here. "Squeak::Object" describes the
> 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
> 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
> sorts of questions like "what happens if I import A and B and then
> 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
> 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
> look like:
> self import: A::Foo as: #Foo.
> self import: A::Bar as: #Bar.
> self import: A::Mumble as: #Mumble.
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:
> 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.
More information about the Squeak-dev