[Traits] Namespaces(environments?), SystemChangeNotifier, ...

stéphane ducasse ducasse at iam.unibe.ch
Mon Apr 24 09:29:50 UTC 2006


I would like to understand the proposal of goran, since I'm  
***really*** relunctant to namespace introduction
at the language level (when I see what we got in VW).

Now we developed a class Namespace to support the system at the  
infrastructural level (having a class that plays the system
dictionary role but only that one and not mixed with everything). You  
can find the code on squeaksource.

Now the point is to pay attention that the system can absorb changes  
and evolved smoothly, for me the next challenge
is the integration of packages (replacing category which could be  
only there when MC is not loaded) and speeding
MC...

Stef

On 24 avr. 06, at 10:40, Klaus D. Witzel wrote:

> List,
>
> for a new project we plan to create a namespace which can and will  
> have names clashing with existing global names like Object[tm] and  
> Process[tm]. All behavior will be specified in form of Traits (for  
> the immediate future only classTraits).
>
> We've looked around in the Traits implementation [3.9a] and found a  
> good namespace separation example, [self environment organization],  
> but there also is [SystemChangeNotifier uniqueInstance] which seems  
> to know nothing about possible name clashes.
>
> What is the status, are the plans for having 100%[tm] separated  
> namespaces? Google found
> - http://lists.squeakfoundation.org/pipermail/squeak-dev/2004- 
> December/085761.html
> was there anything else we should take care of?
>
> The new name space we have in mind derives from ontologies and we  
> don't want to force users of an ontology namespace to prefix or  
> suffix any names/identifiers.
>
> And while we are at it, how should an object (say, a Class) use  
> objects from another namespace (say, a Traits), and what about  
> namespace separation in #definitionST80.
>
> But perhaps there are other and/or better ideas on how to separate  
> namespaces in Squeak, suggestions and/or experience, all appreciated.
>
> /Klaus
>
> P.S. Of course we already have some ideas (and working code  
> examples) on how to address these issues but would naturally like  
> to hear voices from the community.
>
>




More information about the Squeak-dev mailing list