I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring.. And this difference is a bit frustrating to me, especially when code which have to be ported from Squeak, i need to visit all the places and fix the references.
I was not here when this change was introduced, and you maybe know , that i'm a heated enemy of global state. But i understand the reasoning of dissection the Smalltalk dictionary of globals from the rest of service methods & additional state, which is needed and which were putted in SmalltalkImage class.
But the more i thinking about it, the more i feel that this 'dissection' can be done in least intrusive way which is much friendlier to 'old ways' but also plays well with 'current ways'.
So, what i'm proposing:
- make a dictionary of globals a pure dictionary, without any extra unrelated methods. - completely move all fat stuff into SmalltalkImage from SystemDictionary class - add 'globals' ivar to SmalltalkImage class , and add proxy methods for accessing the dictionary, like #at: #at:put: etc.
then simply: Smalltalk at: #Smalltalk put: (SmalltalkImage current).
Now, Smalltalk == SmalltalkImage current and everyone is happy: - dictionary lives in separate ivar, - fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
On Fri, 24 Jul 2009 12:27:36 +0200, Igor Stasenko wrote:
I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring.. And this difference is a bit frustrating to me, especially when code which have to be ported from Squeak, i need to visit all the places and fix the references.
I was not here when this change was introduced, and you maybe know , that i'm a heated enemy of global state. But i understand the reasoning of dissection the Smalltalk dictionary of globals from the rest of service methods & additional state, which is needed and which were putted in SmalltalkImage class.
But the more i thinking about it, the more i feel that this 'dissection' can be done in least intrusive way which is much friendlier to 'old ways' but also plays well with 'current ways'.
So, what i'm proposing:
- make a dictionary of globals a pure dictionary, without any extra
unrelated methods.
- completely move all fat stuff into SmalltalkImage from
SystemDictionary class
- add 'globals' ivar to SmalltalkImage class , and add proxy methods
for accessing the dictionary, like #at: #at:put: etc.
then simply: Smalltalk at: #Smalltalk put: (SmalltalkImage current).
This part will not work, check yourself:
(Smalltalk associationAt: #Smalltalk) inspect
/Klaus
Now, Smalltalk == SmalltalkImage current and everyone is happy:
- dictionary lives in separate ivar,
- fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
2009/7/24 Klaus D. Witzel klaus.witzel@cobss.com:
On Fri, 24 Jul 2009 12:27:36 +0200, Igor Stasenko wrote:
I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring.. And this difference is a bit frustrating to me, especially when code which have to be ported from Squeak, i need to visit all the places and fix the references.
I was not here when this change was introduced, and you maybe know , that i'm a heated enemy of global state. But i understand the reasoning of dissection the Smalltalk dictionary of globals from the rest of service methods & additional state, which is needed and which were putted in SmalltalkImage class.
But the more i thinking about it, the more i feel that this 'dissection' can be done in least intrusive way which is much friendlier to 'old ways' but also plays well with 'current ways'.
So, what i'm proposing:
- make a dictionary of globals a pure dictionary, without any extra
unrelated methods.
- completely move all fat stuff into SmalltalkImage from SystemDictionary
class
- add 'globals' ivar to SmalltalkImage class , and add proxy methods
for accessing the dictionary, like #at: #at:put: etc.
then simply: Smalltalk at: #Smalltalk put: (SmalltalkImage current).
This part will not work, check yourself:
(Smalltalk associationAt: #Smalltalk) inspect
in what way it wont work? I can implement #associationAt: in SmalltalkImage class, to proxy it to globals ivar. What's wrong with it? Or do you mean, that we will end up with the need of proxying all Collection protocol methods? There always can be more radical solutions, like proxying rest of stuff through DNU handler :)
/Klaus
Now, Smalltalk == SmalltalkImage current and everyone is happy: - dictionary lives in separate ivar, - fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
On Fri, 24 Jul 2009 12:39:07 +0200, Igor Stasenko wrote:
2009/7/24 Klaus D. Witzel :
...
So, what i'm proposing:
...
then simply: Smalltalk at: #Smalltalk put: (SmalltalkImage current).
This part will not work, check yourself:
(Smalltalk associationAt: #Smalltalk) inspect
in what way it wont work?
I was responding to a practical issue, not a conceptual one; try
Smalltalk at: #Smalltalk put: Smalltalk
then you should see why that's not possible.
I can implement #associationAt: in SmalltalkImage class, to proxy it to globals ivar. What's wrong with it?
With #associationAt: in SmalltalkImage? nothing, if it still makes sense.
Or do you mean, that we will end up with the need of proxying all Collection protocol methods?
Some of them: yes; unless you get rid of "Dictionary" users' view.
There always can be more radical solutions, like proxying rest of stuff through DNU handler :)
:)
/Klaus
2009/7/24 Klaus D. Witzel klaus.witzel@cobss.com:
On Fri, 24 Jul 2009 12:39:07 +0200, Igor Stasenko wrote:
2009/7/24 Klaus D. Witzel :
...
So, what i'm proposing:
...
then simply: Smalltalk at: #Smalltalk put: (SmalltalkImage current).
This part will not work, check yourself:
(Smalltalk associationAt: #Smalltalk) inspect
in what way it wont work?
I was responding to a practical issue, not a conceptual one; try
Smalltalk at: #Smalltalk put: Smalltalk
then you should see why that's not possible.
I don't see how this can be a barrier of any sort for a real hacker:
(Smalltalk associationAt: #Smalltalk) becomeForward: (#Smalltalk -> Smalltalk).
Smalltalk at: #Smalltalk put: Smalltalk
There are numerous ways how to get around this ;) Btw, this is another reason to not expose messages like #associationAt: to users. Alas, associations is used by compiler. :(
I can implement #associationAt: in SmalltalkImage class, to proxy it to globals ivar. What's wrong with it?
With #associationAt: in SmalltalkImage? nothing, if it still makes sense.
Or do you mean, that we will end up with the need of proxying all Collection protocol methods?
Some of them: yes; unless you get rid of "Dictionary" users' view.
There always can be more radical solutions, like proxying rest of stuff through DNU handler :)
:)
/Klaus
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, 24 Jul 2009 13:53:47 +0200, Igor Stasenko wrote:
2009/7/24 Klaus D. Witzel :
...
I was responding to a practical issue, not a conceptual one; try
Smalltalk at: #Smalltalk put: Smalltalk
then you should see why that's not possible.
I don't see how this can be a barrier of any sort for a real hacker:
(Smalltalk associationAt: #Smalltalk) becomeForward: (#Smalltalk -> Smalltalk).
Smalltalk at: #Smalltalk put: Smalltalk
There are numerous ways how to get around this ;)
Have you considered rehash, .image save & load ? I've thought about replacing (Smalltalk associationAt: #Smalltalk)'s value many times and don't want to risk other people's .images just because of *any* silly mistake. That's why I'm interested in solutions to the practical side.
Btw, this is another reason to not expose messages like #associationAt: to users.
Yes, one reason is: do not expose #pointersTo:, since then #associationAt: can be simulated. And just another one: do not expose #someObject or #nextObject ( & friends), since then #pointersTo: can be simulated. (cough) back to Smalltalk? :)
Alas, associations is used by compiler. :(
Sure.
/Klaus
2009/7/24 Klaus D. Witzel klaus.witzel@cobss.com:
On Fri, 24 Jul 2009 13:53:47 +0200, Igor Stasenko wrote:
2009/7/24 Klaus D. Witzel :
...
I was responding to a practical issue, not a conceptual one; try
Smalltalk at: #Smalltalk put: Smalltalk
then you should see why that's not possible.
I don't see how this can be a barrier of any sort for a real hacker:
(Smalltalk associationAt: #Smalltalk) becomeForward: (#Smalltalk -> Smalltalk).
Smalltalk at: #Smalltalk put: Smalltalk
There are numerous ways how to get around this ;)
Have you considered rehash, .image save & load ?
Since i'm not touching the key - #Smalltalk, such change is immune from potential hashing issues. And yes, i saved & loaded image after this brutal hack. It works as usual.
I've thought about replacing (Smalltalk associationAt: #Smalltalk)'s value many times and don't want to risk other people's .images just because of *any* silly mistake. That's why I'm interested in solutions to the practical side.
well this could be done once, tested & shipped with new "core" image. So you never need to be bothered with this again.
Btw, this is another reason to not expose messages like #associationAt: to users.
Yes, one reason is: do not expose #pointersTo:, since then #associationAt: can be simulated. And just another one: do not expose #someObject or #nextObject ( & friends), since then #pointersTo: can be simulated. (cough) back to Smalltalk? :)
Right, lets better discuss the pros and cons of such change instead of harms to Smalltalk association :)
Alas, associations is used by compiler. :(
Sure.
/Klaus
On Fri, Jul 24, 2009 at 6:27 AM, Igor Stasenko siguctua@gmail.com wrote:
Now, Smalltalk == SmalltalkImage current and everyone is happy:
- dictionary lives in separate ivar,
- fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
I particularly like this idea from the standpoint of delivering a modules that exist within their own context. It is actually not that dissimilar from Forth systems that use different vocabs to support multiple incompatible applications at the same time.
Something like this would solve one of the problems I've been running into recently, where some code keeps mucking up the SystemDictionary's associations causing the Compiler to error out.
Dave
Igor Stasenko wrote:
I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring..
Ah, one of my favorite rant subjects. First, it's not a refactoring; refactorings leave the public interfaces intact (I really hate it when people call random rewrites "refactoring" code). Secondly I'm still 100% behind what I wrote here about Smalltalk vs. "SamlltalkImage current":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/118175.html
I'm very glad to hear that Cuis doesn't use SmalltalkImage.
Now, Smalltalk == SmalltalkImage current and everyone is happy:
- dictionary lives in separate ivar,
- fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
I think it's a definitive improvement to the current situation.
Cheers, - Andreas
Andreas Raab wrote:
Igor Stasenko wrote:
I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring..
Ah, one of my favorite rant subjects. First, it's not a refactoring; refactorings leave the public interfaces intact (I really hate it when people call random rewrites "refactoring" code). Secondly I'm still 100% behind what I wrote here about Smalltalk vs. "SamlltalkImage current":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/118175.html
I'm very glad to hear that Cuis doesn't use SmalltalkImage.
I totally agree with Andreas.
Now, Smalltalk == SmalltalkImage current and everyone is happy:
- dictionary lives in separate ivar,
- fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
I think it's a definitive improvement to the current situation.
The compatibility trick I suggest for Cuis is really easy. Just add SmalltalkImage as a new, empty class, with just one class method 'current ^Smalltalk'. Simple, clean, and compatible with both original and 'SmalltalkImage current' idiom.
Cheers,
- Andreas
Cheers, Juan Vuletich
On Fri, Jul 24, 2009 at 02:07:20PM -0300, Juan Vuletich wrote:
Andreas Raab wrote:
Igor Stasenko wrote:
I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring..
Ah, one of my favorite rant subjects. First, it's not a refactoring; refactorings leave the public interfaces intact (I really hate it when people call random rewrites "refactoring" code). Secondly I'm still 100% behind what I wrote here about Smalltalk vs. "SamlltalkImage current":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/118175.html
I'm very glad to hear that Cuis doesn't use SmalltalkImage.
I totally agree with Andreas.
Now, Smalltalk == SmalltalkImage current and everyone is happy:
- dictionary lives in separate ivar,
- fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
I think it's a definitive improvement to the current situation.
The compatibility trick I suggest for Cuis is really easy. Just add SmalltalkImage as a new, empty class, with just one class method 'current ^Smalltalk'. Simple, clean, and compatible with both original and 'SmalltalkImage current' idiom.
This sounds like a good way to handle it. There are some external packages that need to use the "SmalltalkImage current" idiom when loaded into one version of Squeak, and "Smalltalk" for all the rest. It would be good to keep "SmalltalkImage current" in place for compatibility, even if it does not make any sense beyond that.
BTW, I don't know whether to laugh or cry when I read the class comment for SmalltalkImage: "I represent the SmalltalkImage and partly the VM."
Dave
On Fri, Jul 24, 2009 at 9:38 AM, Andreas Raab andreas.raab@gmx.de wrote:
Igor Stasenko wrote:
I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring..
Ah, one of my favorite rant subjects. First, it's not a refactoring; refactorings leave the public interfaces intact (I really hate it when people call random rewrites "refactoring" code). Secondly I'm still 100% behind what I wrote here about Smalltalk vs. "SamlltalkImage current":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/118175.html
I'm very glad to hear that Cuis doesn't use SmalltalkImage.
+10.
Now, Smalltalk == SmalltalkImage current and everyone is happy:
- dictionary lives in separate ivar,
- fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
I think it's a definitive improvement to the current situation.
Cheers,
- Andreas
I see no reason why it should not be possible to break an existing API. However, to make this possible, it should be the responsibility of the breaker to: 1) Provide backward compatibility patch (that will eventually later be deprecated) I would prefer it to be an add-on package (like CompatibilityWith39), if moving methods across packages were not so messy... 2) Provide guidelines for easing transition (where? a wiki? and/or a ReleaseNotes.txt distributed with the image?) Even better if some automated rewrite rules are also provided. 3) and of course, provide a good rationale in preamble to any such change
Nicolas
2009/7/24 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
I am currently using the Cuis, which doesn't having a 'SmalltalkImage current' refactoring..
Ah, one of my favorite rant subjects. First, it's not a refactoring; refactorings leave the public interfaces intact (I really hate it when people call random rewrites "refactoring" code). Secondly I'm still 100% behind what I wrote here about Smalltalk vs. "SamlltalkImage current":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/118175.html
I'm very glad to hear that Cuis doesn't use SmalltalkImage.
Now, Smalltalk == SmalltalkImage current and everyone is happy: - dictionary lives in separate ivar, - fat & boring housekeeping stuff lives in SmalltalkImage instance.
What you think?
I think it's a definitive improvement to the current situation.
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
David Goehrig -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
Joshua Gargus -
Juan Vuletich -
Klaus D. Witzel -
Nicolas Cellier