[Pharo-project] Pharo and Namespaces

Frank Shearar frank.shearar at gmail.com
Tue Jun 26 17:32:11 EDT 2012


On 26 June 2012 22:17, camille teruel <camille.teruel at gmail.com> wrote:
> As far as I understand the video of Germán's implementation, the import's
> granularity is at the environment level, for both source-side and sink-side,
> not at class level: he imports a whole environment into another. All the
> class defined inside the source environment become accessible to the sink
> environment without prefixing with the source environment name.
>
> IMO, the problems of importing a whole namespace into another are:
>
> you have to manage name clashes.
>
> Ex: you have a namespace A that imports namespaces B and C developped by
> some other guys, then a guy add a class to B whose name is already used in C
> for another class that A uses => A is now broken.
>
> you can't see how many dependencies a namespace has without doing some code
> analysis.
>
>
> However if you makes your imports class by class, you can see how many
> dependency a namespace has and you are always sure that your code refers to
> the classes you want.
>
>> I just say that changing binding of variables at the class level is not a
>> good granularity. I do not want to have
>> Object subclass: #NameOfSubclass
>>        instanceVariableNames: ''
>>        classVariableNames: ''
>>        poolDictionaries: ''
>>        category: 'Bob'
>> >>>     environment:
>
>
> You have to specify in which environment a class is at some point. If you
> look at class builder, there is the super long method:
> #name:inEnvironment:subclassOf:......
> For the moment, the environment is always the system dictionary. But if you
> have several environements, you'll have to add the extra argument you don't
> want when creating new classes.

No: you store the current environment in a dynamic variable.
ClassBuilder's convenience method checks the value of that variable,
and you're done.

If you look at the squeak-dev archives for today you'll see Colin
Putney's Environment prototype which does exactly that.

frank

> BTW, do we want to have just namespace categories or a hierachical namespace
> imbrication?




More information about the Pharo-dev mailing list