Am 14.12.2013 um 12:09 schrieb kilon alios <[email protected]>: > why we need globals anyway ? why not use classes instead ? >
Class names are globals. A class is registered in a global namespace by its name. Names need to be looked up. How should it work in another way? Norbert > The only use I see of globals is in workspace and I am sure we could find a > way to automate or make the creation of classes faster inside workspace > instead of using globals. Since OO is the very foundation of Pharo I don't > see why one would need globals anyway. If that forces us to make object more > flexible so be it. Way better than creating concepts that works with this > tools and not work with the other tool or could work if you do this and that > , ending up making things more complex than they need to be. > > I think it would make even the transition from workspace to browser easier, > or even completely replace workspace with the browser. > > I always found workspace unnecessary anyway. > > > On Sat, Dec 14, 2013 at 12:47 PM, Norbert Hartl <[email protected]> wrote: > > > > Am 14.12.2013 um 05:41 schrieb Igor Stasenko <[email protected]>: > > > > > > As you may know, smalltalk global dictionary contain all symbols defined > > globally, > > so you can access them directly in any piece of code i.e. when you write: > > > > Object new > > > > it actually means 'send message #new to object, associated with #Object > > name in globals dictionary. > > > > Most of globals are classes, but some of them , like Transcript, World, > > Display etc are not. > > And i was always thinking there's something wrong with these globals > > (actually there's multiple 'wrongs'), but finally, i think i can answer > > myself, what is most basic wrong with them: they miss any form of > > declaration. > > > > Most of variables in smalltalk require declaration, such as temps, method > > arguments, instance variables , class variables, pool variables, > > but not globals. > > Even classes, from formal point of view do not require declaration, > > because actually the usual: > > > > Object subclass: #Collection > > instanceVariableNames: '' > > classVariableNames: 'MutexForPicking RandomForPicking' > > poolDictionaries: '' > > category: 'Collections-Abstract' > > > > is _definition_ but not declaration: > > > > Collection definition => > > > > 'Object subclass: #Collection > > instanceVariableNames: '''' > > classVariableNames: ''MutexForPicking RandomForPicking'' > > poolDictionaries: '''' > > category: ''Collections-Abstract''' > > > > in fact, it is just a message sent to 'Object' variable (at some moment in > > the past) , and there's nothing > > in language which enforces the rule that evaluating such expression must > > declare new global, named Collection, except from environment we're working > > in. > > > > The absence of declaration for globals leads to following problems: > > since declaration point is not defined, all tools (including compiler) > > assume that given name always been there, and always accessible. Which > > leads to bootstrap problems. > > There's no way to determine if given piece of code (which uses some global) > > will keep functioning properly, once you unload certain package. No way to > > determine dependencies (and as consequence the order of code loading during > > bootstrapping). > > Also, it is hard to determine, to which package certain global belongs. > > While it is easy to tell for classes since they having category, for > > globals like Transcript, Display etc, there's no way to tell anything. > > Piece of cake, you can say: since Display is instance of DisplayScreen > > class, then such variable must belong to same package as DisplayScreen, > > right? > > Wrong! > > Just for example, imagine i create variable named MyWindowMousePosition, > > which will contain an instance of Point. Does it means that such variable > > should belong to same package as Point class? I guess not. > > > > So, to sum up, i think we should really think how to introduce a way to > > declare globals in package-based ecosystem, where each global belongs to > > certain package, and then since packages form dependency hierarchy, you can > > easily detect whether you allowed to use certain global in given context or > > not, > > to prevent forming dependency loops. > > But even if we will weaken contract and allow having dependency loops, even > > in such case declarations can help us to clearly tell which pieces of code > > will stop functioning properly, if package which declares given variable > > are not present in system. > > > > The last aspect of bootstrapping problem is order of initialization, > > because declaring variable doesn't means you can use it right away, > > since it may be not properly initialized yet (otherwise we will be forced > > to always use lazy initialization pattern). > > > > From this perspective, IMO package should not only have unordered list of > > classes/symbols it declares/defines, but also contain information in which > > order they must be initialized while loaded. > > From other side, i don't really like introducing too much formalism and > > rules, and keep them as minimal as possible, following smalltalk spirit. > > > > What you think? > > I think packages should be first class citizens. A package once loaded > provides an environment/namespace/... that declares all the (exported) > symbols that should be accesible global. The smalltalk dictionary should > rather be a list of those namespaces/environments/... A package should also > have an initialize method where you could specify order of class > initialization if necessary ( and other things). Furthermore I would like to > see class initializers idempotent. So when loading a package the package > initialize is invoked first and then the class initializers, As they are > idempotent a possible double invocation is not a problem. > Dependencies are always hard. I would start thinking about metacello defining > all the possible dependencies regarding platforms, platform versions etc. At > load time there is only one dependency graph and that could be reflected by > the system. And this graph is not dependent on the tool that loaded the code. > With this in place unloading should be rather easy. Dependencies can warn the > user about an harmful action and when the namespace is removed all global > definitions are automaticall removed. > > That is what I think. But I also think that there should be a possibility to > load something that doesn't end being global. A way to load a package that > isn't added to the global namespace (smalltalk dictionary) but to a package > namespace would also be very good. Not everything needs to global but we can > only load global things. That is a flaw in my opinion. And it prevents cool > things like loading multiple versions of a code in separate packages. > > Norbert >
