On 26 June 2012 22:17, camille teruel <[email protected]> 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?
