Namespaces (was: Re: [ANN]A plan for 3.8/4.0... (insertdrumroll here))

stéphane ducasse ducasse at iam.unibe.ch
Fri Apr 2 07:04:13 UTC 2004


I really think that you should look at classboxes because this is two  
years that we worked on that.
and namespaces do not have really to be hierarchical it depends for  
what you use them.

By the way classbox support locality of methods too. You only see the  
class extensions
you did or one of the classboxes you imported did from your classbox.

Read the paper. Now alex will release a version that does not require  
to modify the VM (for the local rebinding but local rebinding is not  
linked with namespace issues).

stef

On 2 avr. 04, at 02:32, Brian Murphy-Dye wrote:

> I always thought Common Lisp did a good job with packages. If nothing  
> else, it may help to see how some other smart people dealt with these  
> issues. The standard lisp reference manual [Common Lisp The Language,  
> 2nd Edition] is online, with the discussion about packages beginning  
> at:
>      
> http://www.supelec.fr/docs/cltl/clm/ 
> node111.html#SECTION001500000000000000000
>
> IIRC (it's been a couple of years), calling #use-package will use any  
> exported method in the specified package, even if the method is added  
> (and exported) after using the package. Name conflicts was a big  
> concern to them as well and is discussed at:
>      
> http://www.supelec.fr/docs/cltl/clm/ 
> node116.html#SECTION001550000000000000000
> Basically, any name conflict raises an error, forcing one of the  
> methods to be renamed in the use-package call.
>
> You can also import specific methods similar to your #import:as:  
> method below.
>
> The name spaces in Common Lisp are not hierarchical, but a package may  
> re-export a variable it has imported, thus providing a sense of  
> hierarchy.
>
> Brian.
>
>
> On Apr 1, 2004, at 4:46 PM, Avi Bryant wrote:
>
>>
>> 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
>>
>>
>
>




More information about the Squeak-dev mailing list