[Pharo-dev] Another thought about globals

kilon alios kilon.alios at gmail.com
Sat Dec 14 11:24:17 EST 2013


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 <norbert at hartl.name> wrote:

>
> Am 14.12.2013 um 16:17 schrieb kilon alios <kilon.alios at gmail.com>:
>
> 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 <norbert at hartl.name> wrote:
>
>>
>> Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios at gmail.com>:
>>
>> 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 <norbert at hartl.name>wrote:
>>
>>>
>>> Am 14.12.2013 um 12:09 schrieb kilon alios <kilon.alios at gmail.com>:
>>>
>>> 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 <norbert at hartl.name>wrote:
>>>
>>>>
>>>>
>>>> > Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua at gmail.com>:
>>>> >
>>>> >
>>>> > 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
>>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131214/ffd5bcba/attachment-0002.html>


More information about the Pharo-dev mailing list