Another thought about globals
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? -- Best regards, Igor Stasenko.
Hi Igor, What about scanning for globals in the code? And just a proper way to declare globals somewhere in a package should be about enough (loading scripts can take care of the initialisation, no?). Or... All globals are classes, or accessed via classes (singleton pattern). Like that you get everything correct (loading order, package ownership, initialization) and you don't have to create new rules, just produce better code. Would you have a counter example to that ? (i.e. a currently existing Global in Pharo which cannot be reimplemented as a class with some state in it?) Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Igor Stasenko [siguctua@gmail.com] Date d'envoi : samedi 14 décembre 2013 05:41 à : Discusses Development of Pharo Objet : [Pharo-dev] Another thought about globals 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? -- Best regards, Igor Stasenko.
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
why we need globals anyway ? why not use classes instead ? 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@hartl.name> wrote:
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
Am 14.12.2013 um 12:09 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
yes sorry i meant global variables , the ones you define in workspace like a := 1. On Sat, Dec 14, 2013 at 4:30 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.12.2013 um 12:09 schrieb kilon alios <kilon.alios@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@hartl.name>wrote:
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 12:09 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
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. On Sat, Dec 14, 2013 at 5:15 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 12:09 schrieb kilon alios <kilon.alios@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@hartl.name>wrote:
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
Am 14.12.2013 um 16:17 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 12:09 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
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@hartl.name> wrote:
Am 14.12.2013 um 16:17 schrieb kilon alios <kilon.alios@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@hartl.name> wrote:
Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios@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@hartl.name>wrote:
Am 14.12.2013 um 12:09 schrieb kilon alios <kilon.alios@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@hartl.name>wrote:
Am 14.12.2013 um 05:41 schrieb Igor Stasenko <siguctua@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
On 14 Dec 2013, at 16:15, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios@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.
They live in the âbindingsâ ivar of Workspace. When you compile code with the ârequestorâ not nil, it will put a OCRequestorScope into the scope chain. This means that when Opal Semantic analysis asks the scope for the definition of a name, it will call #lookupVar: on that scope, which is then doing: (requestor bindingOf: name asSymbol) ifNotNil: [:assoc | ^ OCLiteralVariable new assoc: assoc; scope: self; yourself]. ^ super lookupVar: name. Which means that variables in the Workspace are compiled as literal variables (like globals), but the binding comes from a dictionary that is in the ivar âbindingsâ of the Workspace. Marcus
Would be nice to have a view on them like in VW. On Saturday, December 14, 2013, Marcus Denker wrote:
On 14 Dec 2013, at 16:15, Norbert Hartl <norbert@hartl.name<javascript:_e({}, 'cvml', 'norbert@hartl.name');>> wrote:
Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios@gmail.com<javascript:_e({}, 'cvml', 'kilon.alios@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.
They live in the âbindingsâ ivar of Workspace.
When you compile code with the ârequestorâ not nil, it will put a OCRequestorScope into the scope chain. This means that when Opal Semantic analysis asks the scope for the definition of a name, it will call #lookupVar: on that scope, which is then doing:
(requestor bindingOf: name asSymbol) ifNotNil: [:assoc | ^ OCLiteralVariable new assoc: assoc; scope: self; yourself]. ^ super lookupVar: name.
Which means that variables in the Workspace are compiled as literal variables (like globals), but the binding comes from a dictionary that is in the ivar âbindingsâ of the Workspace.
Marcus
-- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
Hi Norbert--
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?
Get rid of globals. Make the root classes elements of the special objects array (Object already is), and look up classes through that. Make everything else that used to be a global (like Transcript) the responsibility of some class, and use them by sending messages. This also makes the modularization straightforward. There's no need for a system dictionary. It was a profound and long-lived mistake. -C -- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)
Yes thats exactly what I meant with my reply. I was not so sure though about the exact role of globals in pharo and how many problems their removal would cause internally. ΣÏÎ¹Ï 14 Îεκ 2013 9:39 μ.μ., ο ÏÏήÏÏÎ·Ï "Craig Latta" <craig@netjam.org> ÎγÏαÏε:
Hi Norbert--
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?
Get rid of globals. Make the root classes elements of the special objects array (Object already is), and look up classes through that. Make everything else that used to be a global (like Transcript) the responsibility of some class, and use them by sending messages. This also makes the modularization straightforward.
There's no need for a system dictionary. It was a profound and long-lived mistake.
-C
-- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)
Hi Norbert--
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?
Get rid of globals. Make the root classes elements of the special objects array (Object already is), and look up classes through that. Make everything else that used to be a global (like Transcript) the responsibility of some class, and use them by sending messages. This also makes the modularization straightforward.
This is what we did with Smalltalk -> self environment. Smalltalk -> SmalltalkImage current Now I wonder if it really solves the problem that has igor (this is true that I would prefer to avoid to have specific declaration. Now what would be good is to have a protocol to systematically initialize such "global" even when they are attached to classes.
There's no need for a system dictionary. It was a profound and long-lived mistake.
In the midterm I want to get rid of it (by splitting it and distributing into module) but it will take time.
Am 14.12.2013 um 21:08 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi Norbert--
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?
Get rid of globals. Make the root classes elements of the special objects array (Object already is), and look up classes through that. Make everything else that used to be a global (like Transcript) the responsibility of some class, and use them by sending messages. This also makes the modularization straightforward.
This is what we did with Smalltalk -> self environment. Smalltalk -> SmalltalkImage current
Now I wonder if it really solves the problem that has igor (this is true that I would prefer to avoid to have specific declaration. Now what would be good is to have a protocol to systematically initialize such "global" even when they are attached to classes.
What speaks against Package>>#initialize ? Or package having a selector returning the list of package wide globals and a selector for each global to create the value for it? What is the difference between a dependency to a package and the access to its globals? Shouldn't the package not having defined its dependencies and couldn't that mean the same information composes the "global" namespace for this package? Norbert
There's no need for a system dictionary. It was a profound and long-lived mistake.
In the midterm I want to get rid of it (by splitting it and distributing into module) but it will take time.
On Dec 15, 2013, at 11:22 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.12.2013 um 21:08 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi Norbert--
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?
Get rid of globals. Make the root classes elements of the special objects array (Object already is), and look up classes through that. Make everything else that used to be a global (like Transcript) the responsibility of some class, and use them by sending messages. This also makes the modularization straightforward.
This is what we did with Smalltalk -> self environment. Smalltalk -> SmalltalkImage current
Now I wonder if it really solves the problem that has igor (this is true that I would prefer to avoid to have specific declaration. Now what would be good is to have a protocol to systematically initialize such "global" even when they are attached to classes.
What speaks against Package>>#initialize ?
You cannot easily build tools with this approach
Or package having a selector returning the list of package wide globals and a selector for each global to create the value for it?
would be much better
What is the difference between a dependency to a package and the access to its globals? Shouldn't the package not having defined its dependencies and couldn't that mean the same information composes the "global" namespace for this package?
I could not understand what you meant :)
Norbert
There's no need for a system dictionary. It was a profound and long-lived mistake.
In the midterm I want to get rid of it (by splitting it and distributing into module) but it will take time.
Am 14.12.2013 um 20:38 schrieb Craig Latta <craig@netjam.org>:
Hi Norbert--
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?
Get rid of globals. Make the root classes elements of the special objects array (Object already is), and look up classes through that. Make everything else that used to be a global (like Transcript) the responsibility of some class, and use them by sending messages. This also makes the modularization straightforward.
There's no need for a system dictionary. It was a profound and long-lived mistake.
Sure. What I wrote before was implying exactly that. There are no globals except those few they are always there. The hard thing is always finding/composing stuff so it can be used. Not having a clever way to do this is preventing us from having namespaces. When this is solved I think it is not too hard to have more than one special objects array. This will bring us to object spaces within the same memory space. Norbert
-C
-- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)
participants (8)
-
Craig Latta -
GOUBIER Thierry -
Igor Stasenko -
kilon alios -
Marcus Denker -
Norbert Hartl -
phil＠highoctane.be -
Stéphane Ducasse