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.

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

Reply via email to