there is a copy paste ? wow pharo really rocks. Thanks I will take a look at compile method.
On Sat, Dec 14, 2013 at 5:47 PM, Norbert Hartl <[email protected]> wrote: > > 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 >>>> >>> >>> >>> >> >> > >
