Hi,
I read in a posting from Andreas that there are problems with the renaming from Smalltalkk to SmalltalkImage current. I discovered problems with it several times myself. That remembers me that I wanted to ask what were the reason to change it? It breaks a lot of code and reading this list it appears to me that nobody likes it :) So how came it has been renamed?
Btw. how much smalltalk images I'm able to run. new is disabled. I don't get it.
Any hint is appreciated.
Norbert
2007/6/28, Norbert Hartl norbert@hartl.name:
I read in a posting from Andreas that there are problems with the renaming from Smalltalkk to SmalltalkImage current. I discovered problems with it several times myself. That remembers me that I wanted to ask what were the reason to change it? It breaks a lot of code and reading this list it appears to me that nobody likes it :) So how came it has been renamed?
I guess it's because Smalltalk is a global variable and global variables should be avoided when possible.
On Jun 28, 2007, at 10:09 AM, Damien Cassou wrote:
2007/6/28, Norbert Hartl norbert@hartl.name:
I read in a posting from Andreas that there are problems with the renaming from Smalltalkk to SmalltalkImage current. I discovered problems with it several times myself. That remembers me that I wanted to ask what were the reason to change it? It breaks a lot of code and reading this list it appears to me that nobody likes it :) So how came it has been renamed?
I guess it's because Smalltalk is a global variable and global variables should be avoided when possible.
This is a good rule of thumb, and will tend to serve well when writing new code (and even for most refactorings). However, for this particular case, I have not heard a compelling argument for how this change increases the utility of the system; to me, it seems to decrease it.
The costs are clear: code is uglier and longer to type, and compatibility is lost between different versions of Squeak. Do the benefits outweigh these costs? Let's see...
One justification for this change might be that it is a step toward not depending on that global variable. This is simply not the case. In order to remove 'Smalltalk', a radical restructuring of the entire system would have to take place. If there was a feasible technical and political plan for this restructuring, then changes such as 'SmalltalkImage current' would be the most trivial and preliminary parts of the plan. In other words, we are no closer to removing 'Smalltalk' as a result of these changes.
'SmalltalkImage current' also early-binds a suggestion about how such a restructuring would look. While it is laudable to aim for a loosely connected network of communicating Smalltalk images, it is not clear what role images themselves should play in structuring object interactions in such a system. For example, the fundamental principles might instead be based on 'namespaces' for code and 'islands' for objects. The point is that we don't know; all we know is that 'SmalltalkImage current' and 'SmalltalkImage otherImageNamed: imageName' are almost certainly wrong.
To me, it seems that the costs and benefits were not carefully considered before the changes were made, because otherwise the changes would not have been made.
(even though I dislike this particular change, I have tremendous respect and appreciation for the efforts of Stephane et. al. to make a better Squeak).
Cheers, Josh
-- Damien Cassou
Hi all--
I'd just like to remind everyone again of my design for shared variables from July of last year[1], implemented in Spoon at that time. I removed SystemDictionary; each class is responsible for its own name literal (so each one appears in only one place, instead of the two we had before). Each class name literal (an association between a symbol and a class object) is unique, so the name symbols need not be. Humans can distinguish classes from one another without regard to name by other means (e.g., author, version, class categories, object identity), with help from the development tools. Given this support, there is no need for namespaces in the common sense; the name symbol of each class can be anything, so in effect each and every class has its own namespace.
As for where to put the behavior formerly provided by the SystemDictionary instance, I prefer that it live at (Interpreter class). A normal system will have only that behavior there, a system with the support to actually build an interpreter will have a bunch more (currently provided by the VMMaker package).
Please see the design for more details.
thanks,
-C
[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)
On 03/07/07, Craig Latta craig@netjam.org wrote:
Hi all--
I'd just like to remind everyone again of my design for sharedvariables from July of last year[1], implemented in Spoon at that time. I removed SystemDictionary; each class is responsible for its own name literal (so each one appears in only one place, instead of the two we had before). Each class name literal (an association between a symbol and a class object) is unique, so the name symbols need not be. Humans can distinguish classes from one another without regard to name by other means (e.g., author, version, class categories, object identity), with help from the development tools. Given this support, there is no need for namespaces in the common sense; the name symbol of each class can be anything, so in effect each and every class has its own namespace.
As for where to put the behavior formerly provided by theSystemDictionary instance, I prefer that it live at (Interpreter class). A normal system will have only that behavior there, a system with the support to actually build an interpreter will have a bunch more (currently provided by the VMMaker package).
Please see the design for more details.
Your solution is good one. And i prefer to see it in future versions of squeak. But this actually raises a more broader question: what to do with global variables, which is identified by name? Can system be designed in such way, that it does not have any global variables (which actually forces us to introduce a structure like SystemDictionary)?
thanks,-C
[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Seems like the idea of "Global Variables" has got a bad name from misuse in other languages. Remember, Smalltalk is an Environment. Globals are good/necessary when appropriate!
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of sig Sent: 03 July 2007 11:39 am To: The general-purpose Squeak developers list Subject: Re: SmalltalkImage current
On 03/07/07, Craig Latta craig@netjam.org wrote:
Hi all--
I'd just like to remind everyone again of my design for sharedvariables from July of last year[1], implemented in Spoon at that time. I removed SystemDictionary; each class is responsible for its own name literal (so each one appears in only one place, instead of the two we had before). Each class name literal (an association between a symbol and a class object) is unique, so the name symbols need not be. Humans can distinguish classes from one another without regard to name by other means (e.g., author, version, class categories, object identity), with help from the development tools. Given this support, there is no need for namespaces in the common sense; the name symbol of each class can be anything, so in effect each and every class has its own namespace.
As for where to put the behavior formerly provided by theSystemDictionary instance, I prefer that it live at (Interpreter class). A normal system will have only that behavior there, a system with the support to actually build an interpreter will have a bunch more (currently provided by the VMMaker package).
Please see the design for more details.
Your solution is good one. And i prefer to see it in future versions of squeak. But this actually raises a more broader question: what to do with global variables, which is identified by name? Can system be designed in such way, that it does not have any global variables (which actually forces us to introduce a structure like SystemDictionary)?
thanks,-C
[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
On Tuesday 03 July 2007 7:53 pm, Gary Chambers wrote:
Seems like the idea of "Global Variables" has got a bad name from misuse in other languages. Remember, Smalltalk is an Environment. Globals are good/necessary when appropriate!
It has to do with scope. A global variable can be modified by any method in the entire image, so it is very vulnerable to unintended modifications. Safe designs use as minimal a scope as possible for variables.
In Squeak, classes are global in scope. With over 2000 of them in newer images, Squeak is as vulnerable as other language environments :-(. Lack of modular scoping mechanisms leads to "Batman" syndrome where programmers use prefixes to mark out scopes - Only BatMan can drive a BatMobile or fly a BatJet fitted with BatWings.
Regards .. Subbu
Hi--
what to do with global variables, which is identified by name?
From the Spoon mailing list message I just mentioned[1]:
***
I addressed the associations [in the SystemDictionary instance] that refer to classes, but there are others. These are the other so-called "global" variables (like Display, the primary display) as well as all the "shared pools" (like TextConstants and, strictly speaking, Undeclared). I think each currently-global variable should be the responsibility of some class. So the primary display could be something you get by sending "primary" to DisplayScreen.
Shared pools are dictionaries of shared-variable associations, similar to the system dictionary (in fact, I'd call the system dictionary just another shared pool). I know some think we should simply banish all shared pools, but I'll assume for the moment that we're keeping them. I find them useful, I just think some class should take responsibility for each one. I've added a "publishedPools" instance variable to Class, which stores all the shared pool dictionaries for which a class has responsibility (i.e., the class that introduced the pool into the system). I renamed the traditional "sharedPools" instance variable in Class to "receivedPools"; these are the pools that a class merely uses. Finally, I renamed the "classPool" instance variable to "classVariablesPool", just to be clearer.
When you want to use a shared pool, you access the pool by sending a message to the responsible class, rather than relying on its name being a "global variable".
***
And to that I'll just add that each responsible class can provide access to individual published variables by direct message when appropriate.
thanks again,
-C
[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Hi craig
what would be a migration strategy and how can we in a piecemeal way (possibly) cherrypick your enhancements?
Stef
Hi--
what to do with global variables, which is identified by name?
From the Spoon mailing list message I just mentioned[1]:
I addressed the associations [in the SystemDictionary instance]that refer to classes, but there are others. These are the other so-called "global" variables (like Display, the primary display) as well as all the "shared pools" (like TextConstants and, strictly speaking, Undeclared). I think each currently-global variable should be the responsibility of some class. So the primary display could be something you get by sending "primary" to DisplayScreen.
Shared pools are dictionaries of shared-variable associations,similar to the system dictionary (in fact, I'd call the system dictionary just another shared pool). I know some think we should simply banish all shared pools, but I'll assume for the moment that we're keeping them. I find them useful, I just think some class should take responsibility for each one. I've added a "publishedPools" instance variable to Class, which stores all the shared pool dictionaries for which a class has responsibility (i.e., the class that introduced the pool into the system). I renamed the traditional "sharedPools" instance variable in Class to "receivedPools"; these are the pools that a class merely uses. Finally, I renamed the "classPool" instance variable to "classVariablesPool", just to be clearer.
When you want to use a shared pool, you access the pool bysending a message to the responsible class, rather than relying on its name being a "global variable".
And to that I'll just add that each responsible class can provideaccess to individual published variables by direct message when appropriate.
thanks again,-C
[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
I like it. Now the final question on road to remove globals at all : what you propose to do with these three symbols: #nil #true #false ? And, maybe this is not related problem - what strategy for accessing class of smallint objects, because there's no direct information in smallint object about its class, because its tagged oop, not mem oop in squeak. I know this is mostly a VM responsibility, but still it introduces a limitations: VM must know a sole instance of SmallInteger class and thus it must be global in VM's context (can't say if it global in language context). And also, if nil object represented by machine word, with all bits = 0, its too , can't point to own class directly.
I assume, these associations must be held somewhere in Interpreter class, because its a reflection of VM (or smalltalk environment).
On 04/07/07, Craig Latta craig@netjam.org wrote:
Hi--
what to do with global variables, which is identified by name?
From the Spoon mailing list message I just mentioned[1]:
I addressed the associations [in the SystemDictionary instance]that refer to classes, but there are others. These are the other so-called "global" variables (like Display, the primary display) as well as all the "shared pools" (like TextConstants and, strictly speaking, Undeclared). I think each currently-global variable should be the responsibility of some class. So the primary display could be something you get by sending "primary" to DisplayScreen.
Shared pools are dictionaries of shared-variable associations,similar to the system dictionary (in fact, I'd call the system dictionary just another shared pool). I know some think we should simply banish all shared pools, but I'll assume for the moment that we're keeping them. I find them useful, I just think some class should take responsibility for each one. I've added a "publishedPools" instance variable to Class, which stores all the shared pool dictionaries for which a class has responsibility (i.e., the class that introduced the pool into the system). I renamed the traditional "sharedPools" instance variable in Class to "receivedPools"; these are the pools that a class merely uses. Finally, I renamed the "classPool" instance variable to "classVariablesPool", just to be clearer.
When you want to use a shared pool, you access the pool by sendinga message to the responsible class, rather than relying on its name being a "global variable".
And to that I'll just add that each responsible class can provideaccess to individual published variables by direct message when appropriate.
thanks again,-C
[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
On Wed, 04 Jul 2007 10:09:30 +0200, sig siguctua@gmail.com wrote:
I like it. Now the final question on road to remove globals at all : what you propose to do with these three symbols: #nil #true #false ? And, maybe this is not related problem - what strategy for accessing class of smallint objects, because there's no direct information in smallint object about its class, because its tagged oop, not mem oop in squeak. I know this is mostly a VM responsibility, but still it introduces a limitations: VM must know a sole instance of SmallInteger class and thus it must be global in VM's context (can't say if it global in language context). And also, if nil object represented by machine word, with all bits = 0, its too , can't point to own class directly.
I assume, these associations must be held somewhere in Interpreter class, because its a reflection of VM (or smalltalk environment).
Indeed, they are. Inspect (Smalltalk specialObjectsArray). And since it's Smalltalk, you can pass your own (0 class) and (nil class) to the VM :)
BTW nil,false,true are associated with their respective bytecode. So compiler knows that VM knows how to access objects in (Smalltalk specialObjectsArray).
/Klaus
On 04/07/07, Craig Latta craig@netjam.org wrote:
Hi--
what to do with global variables, which is identified by name?
From the Spoon mailing list message I just mentioned[1]:
I addressed the associations [in the SystemDictionary instance]that refer to classes, but there are others. These are the other so-called "global" variables (like Display, the primary display) as well as all the "shared pools" (like TextConstants and, strictly speaking, Undeclared). I think each currently-global variable should be the responsibility of some class. So the primary display could be something you get by sending "primary" to DisplayScreen.
Shared pools are dictionaries of shared-variable associations,similar to the system dictionary (in fact, I'd call the system dictionary just another shared pool). I know some think we should simply banish all shared pools, but I'll assume for the moment that we're keeping them. I find them useful, I just think some class should take responsibility for each one. I've added a "publishedPools" instance variable to Class, which stores all the shared pool dictionaries for which a class has responsibility (i.e., the class that introduced the pool into the system). I renamed the traditional "sharedPools" instance variable in Class to "receivedPools"; these are the pools that a class merely uses. Finally, I renamed the "classPool" instance variable to "classVariablesPool", just to be clearer.
When you want to use a shared pool, you access the pool by sendinga message to the responsible class, rather than relying on its name being a "global variable".
And to that I'll just add that each responsible class can provideaccess to individual published variables by direct message when appropriate.
thanks again,-C
[1] http://tinyurl.com/yn7f9h (lists.squeakfoundation.org)
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
On 04/07/07, Klaus D. Witzel klaus.witzel@cobss.com wrote:
On Wed, 04 Jul 2007 10:09:30 +0200, sig siguctua@gmail.com wrote:
I like it. Now the final question on road to remove globals at all : what you propose to do with these three symbols: #nil #true #false ? And, maybe this is not related problem - what strategy for accessing class of smallint objects, because there's no direct information in smallint object about its class, because its tagged oop, not mem oop in squeak. I know this is mostly a VM responsibility, but still it introduces a limitations: VM must know a sole instance of SmallInteger class and thus it must be global in VM's context (can't say if it global in language context). And also, if nil object represented by machine word, with all bits = 0, its too , can't point to own class directly.
I assume, these associations must be held somewhere in Interpreter class, because its a reflection of VM (or smalltalk environment).
Indeed, they are. Inspect (Smalltalk specialObjectsArray). And since it's Smalltalk, you can pass your own (0 class) and (nil class) to the VM :)
BTW nil,false,true are associated with their respective bytecode. So compiler knows that VM knows how to access objects in (Smalltalk specialObjectsArray).
Ok, so, instead of having multiple globals tied with VM, we having a single one - specialObjectsArray.
The reason why i'm asking to a problem which raised when you using these objects in foreign (Spoon naiads) classes/methods. Its obvious, that smallint/nils in different images can behave differently, because anyone can add new methods or modify existing and then produce code based on these changes. I'm interesting, what solution Craig proposed to solve this problem.
On 28 juin 07, at 19:00, Norbert Hartl wrote:
Hi,
I read in a posting from Andreas that there are problems with the renaming from Smalltalkk to SmalltalkImage current. I discovered problems with it several times myself.
did you report them? Where can we find how to fix them?
you can find the complete motivation in the archives but in a nutshell the point was that Smalltalk is a namespace and that over time it agglomerates a lot of extra behavior (sometimes junk) that has nothing to do with namespace management. But with bookkeeping of the image. We tried to clean it up but we also stopped in the middle since we were pissed off by complains.
That remembers me that I wanted to ask what were the reason to change it? It breaks a lot of code and reading this list it appears to me that nobody likes it :)
Sure easy.....
So how came it has been renamed?
It was not renamed behavior was moved out of SystemDictionary.
Btw. how much smalltalk images I'm able to run. new is disabled. I don't get it.
me neither
Any hint is appreciated.
Norbert
On Fri, 2007-06-29 at 08:02 +0200, stephane ducasse wrote:
On 28 juin 07, at 19:00, Norbert Hartl wrote:
Hi,
I read in a posting from Andreas that there are problems with the renaming from Smalltalkk to SmalltalkImage current. I discovered problems with it several times myself.
did you report them? Where can we find how to fix them?
I meant I had problems with software that had to be changed. And yes I reported it. It was at least RemoteFramebuffer and Glorp where I reported and provided fixes. Do you remember me trying to contact Ian ?
you can find the complete motivation in the archives but in a nutshell the point was that Smalltalk is a namespace and that over time it agglomerates a lot of extra behavior (sometimes junk) that has nothing to do with namespace management. But with bookkeeping of the image. We tried to clean it up but we also stopped in the middle since we were pissed off by complains.
Ah, ok, cleaning up _is_ indeed a good motivation for doing it. Were there alternative suggestions from those who did complain? While this work is stopped in the middle of ... this is still a task to compete it or to roll it back?
What makes me wonder is the fact that most of the bigger changes are discussed here up front and very extensive. So I can't understand why there were so much complaints _after_ the changes.
That remembers me that I wanted to ask what were the reason to change it? It breaks a lot of code and reading this list it appears to me that nobody likes it :)
Sure easy.....
So how came it has been renamed?
It was not renamed behavior was moved out of SystemDictionary.
It sounds good. I'll have a look at it if I find some spare time. Just to figure out what it's all about.
Btw. how much smalltalk images I'm able to run. new is disabled. I don't get it.
me neither
Ok, now I understand why it is like it is. Thanks for explaining your motivation. I didn't want to step on your excellent work I just wasn't able to find anything useful on the net about this change.
thanks,
Norbert
Norbert
After trying to clean SystemDictionary I think that at the end what should be done (I proposed that but we did not do it at the end because we were burnt): - is to keep Smalltalk as a placeholder for image related behavior like saving, abandonning sources,... - have a namespace class which support class/global management I proposed a migration path but (I did not have the energy to have a prototype of what I was proposing May be I should- but back then I was burnt and sick of complains).
I meant I had problems with software that had to be changed. And yes I reported it. It was at least RemoteFramebuffer and Glorp where I reported and provided fixes. Do you remember me trying to contact Ian ?
But did you enter big reports in mantis because this is the only way to keep track of bug and that we can fix and improve them.
you can find the complete motivation in the archives but in a nutshell the point was that Smalltalk is a namespace and that over time it agglomerates a lot of extra behavior (sometimes junk) that has nothing to do with namespace management. But with bookkeeping of the image. We tried to clean it up but we also stopped in the middle since we were pissed off by complains.
Ah, ok, cleaning up _is_ indeed a good motivation for doing it.
We were always aware that we were introducing changes and that it would affect people this is always this tension between moving and staying at the same place.
Were there alternative suggestions from those who did complain?
Not to do it. Smalltalk is cool :) Random refactoring...
While this work is stopped in the middle of ... this is still a task to compete it or to roll it back?
We got sick of squeak. :)
What makes me wonder is the fact that most of the bigger changes are discussed here up front and very extensive. So I can't understand why there were so much complaints _after_ the changes.
because it was incremental and not that discussed. Even if it makes a lot of sense to have SmalltalkImage and SystemDictionary separate classes.
It sounds good. I'll have a look at it if I find some spare time. Just to figure out what it's all about.
Btw. how much smalltalk images I'm able to run. new is disabled. I don't get it.
me neither
Ok, now I understand why it is like it is. Thanks for explaining your motivation. I didn't want to step on your excellent work I just wasn't able to find anything useful on the net about this change.
What I can tell you is that we always try to pay attention and this is also why we got burn. We had this vision (dan one) that a system should be lean and clean that people can really learn from it. Now some decisions were made and may be they were not optimal....
Stef
On Fri, 2007-06-29 at 14:10 +0200, stephane ducasse wrote:
Norbert
After trying to clean SystemDictionary I think that at the end what should be done (I proposed that but we did not do it at the end because we were burnt):
- is to keep Smalltalk as a placeholder for image related behavior
like saving, abandonning sources,...
- have a namespace class which support class/global management
I proposed a migration path but (I did not have the energy to have a prototype of what I was proposing May be I should- but back then I was burnt and sick of complains).
This sounds as the work has to be kept up. If there is a wishlist for 3.11 it should be placed onto it.
I meant I had problems with software that had to be changed. And yes I reported it. It was at least RemoteFramebuffer and Glorp where I reported and provided fixes. Do you remember me trying to contact Ian ?
But did you enter big reports in mantis because this is the only way to keep track of bug and that we can fix and improve them.
No, at the same time trying to find Ian I was asking for the right procedure to solve such kind of bugs. As neither RemoteFrameBuffer nor Glorp are part of squeak I didn't come to the idea using mantis. I'll take a close look at mantis and what/how tickets/bugs are entered. And it is not clear for a newbie that trivial things like "exchange Smalltalk with SmalltalkImage current" is to be put into mantis. If it is just for the record then how should someone know?
you can find the complete motivation in the archives but in a nutshell the point was that Smalltalk is a namespace and that over time it agglomerates a lot of extra behavior (sometimes junk) that has nothing to do with namespace management. But with bookkeeping of the image. We tried to clean it up but we also stopped in the middle since we were pissed off by complains.
Ah, ok, cleaning up _is_ indeed a good motivation for doing it.
We were always aware that we were introducing changes and that it would affect people this is always this tension between moving and staying at the same place.
Yes, that is true. But if I remember it correct I noticed you as a guy who often argues to keep the protocol of objects unchanged. And that doesn't fit into my mind together with removing methods from Smalltalk :) Maybe I don't get you right.
Were there alternative suggestions from those who did complain?
Not to do it. Smalltalk is cool :) Random refactoring...
Stef, I don't understand this, except this is meant ironic. And than I have problems understanding why.
While this work is stopped in the middle of ... this is still a task to compete it or to roll it back?
We got sick of squeak. :)
Same as above. I can't understand this.
What makes me wonder is the fact that most of the bigger changes are discussed here up front and very extensive. So I can't understand why there were so much complaints _after_ the changes.
because it was incremental and not that discussed. Even if it makes a lot of sense to have SmalltalkImage and SystemDictionary separate classes.
Does the release team have absolute powers? :)
It sounds good. I'll have a look at it if I find some spare time. Just to figure out what it's all about.
Btw. how much smalltalk images I'm able to run. new is disabled. I don't get it.
me neither
Ok, now I understand why it is like it is. Thanks for explaining your motivation. I didn't want to step on your excellent work I just wasn't able to find anything useful on the net about this change.
What I can tell you is that we always try to pay attention and this is also why we got burn. We had this vision (dan one) that a system should be lean and clean that people can really learn from it. Now some decisions were made and may be they were not optimal....
I think this is completely normal. That is one reason why I like the squeak community so much. There are a lot of guys with academic background trying to make a good and valuable piece out of squeak. And there are enough people working on concrete projects which most of the time introduce hackish style things into the same thing called squeak. And most of the time they meet on such a list like this one and the discuss in a good way. That is a thing about squeak which is most promising to me.
just my two cents,
Norbert
stephane ducasse wrote:
you can find the complete motivation in the archives but in a nutshell the point was that Smalltalk is a namespace and that over time it agglomerates a lot of extra behavior (sometimes junk) that has nothing to do with namespace management.
Of course the other way to look at it (which is more in line with reality) is that Smalltalk is a representative for the environment and as such includes both a name space and a set of attributes and methods that relate to system-wide behavior. Such as platform information, vm parameters, GC settings, startup/shutdown lists etc. which may be delegated to particular places which implement them but where the "natural" home (the place where the writers of the code wanted it to be found) is in Smalltalk.
That was the prevalent opinion before the cleansing jihads started. At the end of which we are in my opinion in a worse state than where things started: More (and duplicated) code instead of less, no improvements in clarity or understanding (it's just one utility class replaced by another, more obscurely named one), depracation warnings and porting woes. And for what benefit exactly? Saying "SmalltalkImage current platformName" instead of "Smalltalk platformName"? I really urge people to go back to 3.4 and compare Smalltalk back then with Smalltalk + SmalltalkImage today to see if the price is worth paying.
I eventually got so tired about the whole mess that was left behind that in Croquet I simply moved everything back from SmalltalkImage to Smalltalk and only left delegation stubs in SmalltalkImage. So that if you want to type your fingers bloody saying "SmalltalkImage current platformName" be my guest; but really I won't make you. And it will be compatible with other versions (except of course the latest Squeak.org versions but that's not my choice to make).
Cheers, - Andreas
On Fri, 2007-06-29 at 01:04 -0700, Andreas Raab wrote:
stephane ducasse wrote:
you can find the complete motivation in the archives but in a nutshell the point was that Smalltalk is a namespace and that over time it agglomerates a lot of extra behavior (sometimes junk) that has nothing to do with namespace management.
Of course the other way to look at it (which is more in line with reality) is that Smalltalk is a representative for the environment and as such includes both a name space and a set of attributes and methods that relate to system-wide behavior. Such as platform information, vm parameters, GC settings, startup/shutdown lists etc. which may be delegated to particular places which implement them but where the "natural" home (the place where the writers of the code wanted it to be found) is in Smalltalk.
That was the prevalent opinion before the cleansing jihads started. At the end of which we are in my opinion in a worse state than where things started: More (and duplicated) code instead of less, no improvements in clarity or understanding (it's just one utility class replaced by another, more obscurely named one), depracation warnings and porting woes. And for what benefit exactly? Saying "SmalltalkImage current platformName" instead of "Smalltalk platformName"? I really urge people to go back to 3.4 and compare Smalltalk back then with Smalltalk + SmalltalkImage today to see if the price is worth paying.
I eventually got so tired about the whole mess that was left behind that in Croquet I simply moved everything back from SmalltalkImage to Smalltalk and only left delegation stubs in SmalltalkImage. So that if you want to type your fingers bloody saying "SmalltalkImage current platformName" be my guest; but really I won't make you. And it will be compatible with other versions (except of course the latest Squeak.org versions but that's not my choice to make).
Ok, now I have a picture of what it was all about. I understand your point and like to fully agree. Except for the point of delegating back from SmalltalkImage to Smalltalk. Cleaning is an important point. Cleaning at the cost of usability is not. I can imagine that it is good to move implementation from Smalltalk to another place. I can also imagine that there be more classes than just SmalltalkImage to keep moved functionality. But then why it wasn't agreed to
- move implementation to the place where they are kept best - delegate the functionalities from Smalltalk to there respective place
In my opinion that would be the best of both worls. Even if SmalltalkImage would be a very great idea it would have been useful to have a transition phase where the functionality is still reachable from Smalltalk while the cleaning team has time to fiddle the right contruct in the back.
For me it sounds sad that it led to a state of the image which is behind a former status quo (I can't judge with my knowledge). And it doesn't seem there are tensions to solve it in the near future.
I would opt for the sake of not breaking too much software that there should be delegating message from Smalltalk to the SmalltalkImage ones.
Norbert
Il giorno ven, 29/06/2007 alle 01.04 -0700, Andreas Raab ha scritto:
I eventually got so tired about the whole mess that was left behind that in Croquet I simply moved everything back from SmalltalkImage to Smalltalk and only left delegation stubs in SmalltalkImage. So that if you want to type your fingers bloody saying "SmalltalkImage current platformName" be my guest; but really I won't make you. And it will be compatible with other versions (except of course the latest Squeak.org versions but that's not my choice to make).
Interesting. Can I ask why you chose to move everything back to Smalltalk and delegate from SmalltalkImage current to Smalltalk instead of the other way around? Would turning Smalltalk into a full-fledged facade object be a good solution?
Giovanni
Giovanni Corriga wrote:
Interesting. Can I ask why you chose to move everything back to Smalltalk and delegate from SmalltalkImage current to Smalltalk instead of the other way around? Would turning Smalltalk into a full-fledged facade object be a good solution?
It is one possible solution. The reason I decided against it was that if the natural home for those methods is in Smalltalk and if those methods are primitives (which most of them are) then what is the point in delegating again? Like, for example, Smalltalk>>vmParameterAt: which is a comment and then a one-line primitive. Except that in the Squeak.org versions the one-line primitive is replaced with a deprecation warning, a no-comment, and a delegation to SmalltalkImage. And what's that good for?
So I decided that since most of the methods in SmalltalkImage are of that kind it'd be more useful to move them back to where they belong and have SmalltalkImage instead of Smalltalk be the facade. It also means that one may be able to get rid of SmalltalkImage at some point (I'm pretty sure Smalltalk is around to stay ;-)
Cheers, - Andreas
El 6/30/07 3:31 AM, "Andreas Raab" andreas.raab@gmx.de escribió:
So I decided that since most of the methods in SmalltalkImage are of that kind it'd be more useful to move them back to where they belong and have SmalltalkImage instead of Smalltalk be the facade. It also means that one may be able to get rid of SmalltalkImage at some point (I'm pretty sure Smalltalk is around to stay ;-)
Cheers,
- Andreas
Andreas:
I always like this view. Ralph , I wish we could do the "revert to 3.4" for Smalltalk. What is your point in this issue ?
Edgar
2007/6/30, Edgar J. De Cleene edgardec2001@yahoo.com.ar:
El 6/30/07 3:31 AM, "Andreas Raab" andreas.raab@gmx.de escribió:
So I decided that since most of the methods in SmalltalkImage are of that kind it'd be more useful to move them back to where they belong and have SmalltalkImage instead of Smalltalk be the facade. It also means that one may be able to get rid of SmalltalkImage at some point (I'm pretty sure Smalltalk is around to stay ;-)
Cheers,
- Andreas
Andreas:
I always like this view. Ralph , I wish we could do the "revert to 3.4" for Smalltalk. What is your point in this issue ?
Wow, Smalltalk really is Windows. You have to be compatible with every mistake you ever made because your clients will refuse to update their code. There is actually code you there that uses SmalltalkImage current because it was written for 3.9 or 3.8. Do you seriously want to give them deprecation messages?
Philippe
On Jun 30, 2007, at 12:42 , Philippe Marschall wrote:
2007/6/30, Edgar J. De Cleene edgardec2001@yahoo.com.ar:
El 6/30/07 3:31 AM, "Andreas Raab" andreas.raab@gmx.de escribió:
So I decided that since most of the methods in SmalltalkImage
are of
that kind it'd be more useful to move them back to where they
belong and
have SmalltalkImage instead of Smalltalk be the facade. It also
means
that one may be able to get rid of SmalltalkImage at some point
(I'm
pretty sure Smalltalk is around to stay ;-)
Cheers,
- Andreas
Andreas:
I always like this view. Ralph , I wish we could do the "revert to 3.4" for Smalltalk. What is your point in this issue ?
Wow, Smalltalk really is Windows. You have to be compatible with every mistake you ever made because your clients will refuse to update their code. There is actually code you there that uses SmalltalkImage current because it was written for 3.9 or 3.8. Do you seriously want to give them deprecation messages?
What if the "SmalltalkImage current" thing was the mistake? Wouldn't your argument apply either way?
- Bert -
2007/6/30, Bert Freudenberg bert@freudenbergs.de:
On Jun 30, 2007, at 12:42 , Philippe Marschall wrote:
2007/6/30, Edgar J. De Cleene edgardec2001@yahoo.com.ar:
El 6/30/07 3:31 AM, "Andreas Raab" andreas.raab@gmx.de escribió:
So I decided that since most of the methods in SmalltalkImage
are of
that kind it'd be more useful to move them back to where they
belong and
have SmalltalkImage instead of Smalltalk be the facade. It also
means
that one may be able to get rid of SmalltalkImage at some point
(I'm
pretty sure Smalltalk is around to stay ;-)
Cheers,
- Andreas
Andreas:
I always like this view. Ralph , I wish we could do the "revert to 3.4" for Smalltalk. What is your point in this issue ?
Wow, Smalltalk really is Windows. You have to be compatible with every mistake you ever made because your clients will refuse to update their code. There is actually code you there that uses SmalltalkImage current because it was written for 3.9 or 3.8. Do you seriously want to give them deprecation messages?
What if the "SmalltalkImage current" thing was the mistake? Wouldn't your argument apply either way?
Sure.
Philippe
El 6/30/07 7:42 AM, "Philippe Marschall" philippe.marschall@gmail.com escribió:
Wow, Smalltalk really is Windows. You have to be compatible with every
mistake
you ever made because your clients will refuse to update their
code. There is
actually code you there that uses SmalltalkImage
current because it was
written for 3.9 or 3.8. Do you seriously want
to give them deprecation
messages?
Philippe
We could keep SmalltalkImage. Maybe is not a bad idea. And some could complete in some future But compatibility seems more important now.
I don't wish image go blow . And I think masters time is important to waste remembering only a particular Squeak is different.
Edgar
We could keep SmalltalkImage. Maybe is not a bad idea. And some could complete in some future But compatibility seems more important now.
I don't wish image go blow . And I think masters time is important to waste remembering only a particular Squeak is different.
I think it is always worth to also look at other Smalltalk implementations. No Smalltalk that I know of puts all its image related functionality into Smalltalk the root namespace. They all have something like ObjectMemory, ObjectMachine, etc.
Lukas
I don't wish image go blow . And I think masters time is important to waste remembering only a particular Squeak is different.
I think it is always worth to also look at other Smalltalk implementations. No Smalltalk that I know of puts all its image related functionality into Smalltalk the root namespace. They all have something like ObjectMemory, ObjectMachine, etc.
Indeed.... but they should be all fools :)
Stef
PS: I'm not happy with SmalltalkImage (may be with Smalltalk pointing to it, yes). But indeed you are right. Other people faced this problem and they found an OO solution to the problem.
We wanted to have a real namespace class so that we could use it to have a better way of controlling references (for security/classloader like things....) because Smalltalk is really weak to that respect. I still think that having a secure modular but open and reflective system is a really important/exciting goal.
So the goal of cleaning SystemDictionary was to convert it into Namespace. May be it was wrong, still having a separate class to deal with class management is really needed and subclassing from systemDictionary was not a good idea, since there is far more than what is needed.
Now retrospectively I think that SmalltalkImage was a mistake and that creating a separate namespace class was the way to go and that SystemDictionary should delegate to it. Now SystemDictionary as a name for what it does sucks. If Smalltalk would point to an instance of SmalltalkImage then we would not need all these SmalltalkImage current. And we could do Namespace smalltalk at: #Point instead of Smalltalk at: #Point to query class existence.
Retrospectively it was also a mistake for me to invest in Squeak and in the future I will see if we can gather a group of people that just want to have fun building a better system but not taking the responsibility of the rest. Forking is the only way so it should that way.
Stef
Giovanni Corriga wrote:
Interesting. Can I ask why you chose to move everything back to Smalltalk and delegate from SmalltalkImage current to Smalltalk instead of the other way around? Would turning Smalltalk into a full-fledged facade object be a good solution?
It is one possible solution. The reason I decided against it was that if the natural home for those methods is in Smalltalk and if those methods are primitives (which most of them are) then what is the point in delegating again? Like, for example, Smalltalk>>vmParameterAt: which is a comment and then a one-line primitive. Except that in the Squeak.org versions the one-line primitive is replaced with a deprecation warning, a no-comment, and a delegation to SmalltalkImage. And what's that good for?
So I decided that since most of the methods in SmalltalkImage are of that kind it'd be more useful to move them back to where they belong and have SmalltalkImage instead of Smalltalk be the facade. It also means that one may be able to get rid of SmalltalkImage at some point (I'm pretty sure Smalltalk is around to stay ;-)
Cheers,
- Andreas
On Sat, 30 Jun 2007 04:38:11 -0700, stephane ducasse stephane.ducasse@free.fr wrote:
Retrospectively it was also a mistake for me to invest in Squeak and in the future I will see if we can gather a group of people that just want to have fun building a better system but not taking the responsibility of the rest. Forking is the only way so it should that way.
I don't think that's such a horrible or tragic outcome. Squeak benefits greatly from Stephane's work (IMO), so it's a loss in one sense if he decides not to work on it, but at the same time, if he's frustrated by those who are at cross-purposes, a fork is a good solution.
On the one hand, Smalltalk is meant to be altered in dramatic ways, on the other, people are trying to get work done. Those two purposes are going to cross at times.
===Blake===
Hi
This is not about tragedy but about energy and beauty. We have always been influenced by the vision of dan than Smalltalk would be so nice and simple than a single guy could understand it and more important to learn from it. Now it was related to the notion that it is better to learn from clean code than hacks.
Now if at the end of the day you spent a lot of energy just arguing with people then after a while may be you should to do something else of your evenings.
I think that SmalltalkImage is not the best move we did but as lukas remarked other Smalltalk have similar solutions. Now as I said I think that the architecture of Squeak is too old to support solutions that would nicely support security concerns (separate namespace for global.... - I'm not talking about namespace at the language level just at the infrastructure level). So for us cleaning SystemDictionary was justified if we consider it as a namespace. if you take 3.4 you see it more like a aggregate of behavior and a not so cosy one.
So I'm really questioning myself to know what to do in the future.
Stef
I don't think that's such a horrible or tragic outcome. Squeak benefits greatly from Stephane's work (IMO), so it's a loss in one sense if he decides not to work on it, but at the same time, if he's frustrated by those who are at cross-purposes, a fork is a good solution.
On the one hand, Smalltalk is meant to be altered in dramatic ways, on the other, people are trying to get work done. Those two purposes are going to cross at times.
===Blake===
It may seem like there are arguments on on both sides as to where something should "live", and that there is no right answer. But I think there is actually a way to tell if an architectural question has been decided correctly:
The cost of making a change ought to be proportional to the size of the problem, not proportional to the size of the code base.
Thus it is "bad" architecture to have methods on a "namespace" object if (and only if) doing so violates the golden rule.
That might be the case if I have to sort though a lot of crap to tell whether adding or even using something will work. While it is true that adding anything to a "namespace" object increases the amount of stuff to sort though, adding methods does not UNIQUELY do so. Every entry to a SystemDictionary increases the volume in the same way as adding a method.
Another issue is the possibility of conflict. I.e., the name has already been used for some other purpose. Again, the issue is true for methods and for dictionary elements separately, but identically.
I think much of the potential problems are really tools issues. For example, I don't have to worry about learning all the methods if the tools show me elements from orthogonal contexts in separate groups. (Namespace/conflict resolution by context is a little more fundamental.)
I can imagine someone thinking -- "This is all well and good, but the tools are what they are. With the ones we have, I am encouraged to think of methods on a class as being part of that class, and having more stuff on the class makes it too hard to learn, analyze, and decompose for different purposes or deliverables." I think this is actually quite true, but it is not uniquely so for the question at hand -- methods on the Smalltalk object. For example, it is also true for Piers Cawley's idea to add a method to everything that behaves like a collection. With the tools and the language as they are, Piers has more work ahead of him than he should have to in order to create and distribute such an extension and to know that it will be right. But in the SmalltalkDictionary methods case, I just don't see any overt violation of the Golden Rule - even with current tools.
One of the things that excites me about Alan et al's new project is that it seems to me to be dealing with this fairly head on.
On Friday 29 June 2007 11:32 am, stephane ducasse wrote:
you can find the complete motivation in the archives but in a nutshell the point was that Smalltalk is a namespace and that over time it agglomerates a lot of extra behavior (sometimes junk) that has nothing to do with namespace management. But with bookkeeping of the image. We tried to clean it up but we also stopped in the middle since we were pissed off by complains.
That Smalltalk is just a namespace is not obvious. SystemDictionary's comment reads "I represent a special dictionary that supports protocol for asking questions about the structure of the system" :-(. In the absence of explicit objects representing VM (SmalltalkVM?), object memory (SmalltalkObjectMemory?) and so on, it is natural that methods gets aggregated in Smalltalk.
"Smalltalk osVersion" looks easy and intuitive while "SmalltalkImage current osVersion" is cumbersome and counter-intuitive because the image is OS independent. osVersion makes sense only when an image is being interpreted by a particular VM process. If we had a SmalltalkVM object, then "Smalltalk osVersion" could be deprecated.
Of course, it is easy for me to say this now. hindsight is 20/20 :-)
Regards .. Subbu K. K.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Blake -
Craig Latta -
Damien Cassou -
Edgar J. De Cleene -
Gary Chambers -
Giovanni Corriga -
Howard Stearns -
Joshua Gargus -
Klaus D. Witzel -
Lukas Renggli -
Norbert Hartl -
Philippe Marschall -
sig -
stephane ducasse -
subbukk