Am 14.12.2013 um 16:17 schrieb kilon alios <[email protected]>: > ah ok my bad, I learned something new, thank you. Is it possible to embed > this method to a new class ? lets say i like what i did in workspace and send > it directly to a new class. > Sure. You might never heard of it but we call it copy&paste. Works like charm. You just press cmd-a then cmd-c….
Or you decorate the content in the workspace with „MyClass compile: ‚methodName [workspace content] ‚ „ Norbert > > On Sat, Dec 14, 2013 at 5:15 PM, Norbert Hartl <[email protected]> wrote: > > Am 14.12.2013 um 15:58 schrieb kilon alios <[email protected]>: > >> yes sorry i meant global variables , the ones you define in workspace like a >> := 1. >> > Those aren’t globals. Everything you do in the workspace is compiled as > method (UndefinedObect>>#DoIt) and executed. There are only a handful of > global values and there is the smalltalk dictionary where names can be looked > up. > > Norbert > >> >> On Sat, Dec 14, 2013 at 4:30 PM, Norbert Hartl <[email protected]> wrote: >> >> 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 >>> >> >> > >
