SmalltalkImage current vs Smalltalk : plan B
Locked
SmalltalkImage current vs Smalltalk : plan B
 
|
For now, plan A has more votes than plan B.
plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. Let SmalltalkImage current ^Smalltalk for crossfork compatibility plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = SystemDictionary. Use messages indirections like: Smalltalk vm imagePath Smalltalk commandLine optionAt: 2. etc... (see previous thread) At 1st step, they are not much different: both unify Smalltalk and SmalltalkImage current API. Also Plan A is much simpler, thus attractive. But: - Plan A is essentially coming back to 3.8 statu quo. - Plan B is essentially introducing message indirections Advantages of plan B I see for the future: - cleaner separation of concerns - less vulnerable to refactoring (thanks to messages indirection) - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) easier thru messages Last, I do not desesperate to sell plan B to other forks. See the outline pf plan B below. So do you still buy plan A ? Nicolas ------------------------------------------ OUTLINE OF PLAN B : ------------------------------------------ PART I - Fusion of the 2 APIs in 1 1) add a globals instance variable to SmalltalkImage 2) initialize this instance variable SmalltalkImage current globals: Smalltalk 3) implement SystemDictionary methods in use to SmalltalkImage, and redirect them through globals MessageSentToGlobalFinder testMessagesSentToSmalltalk may help 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. PART II - Refactoring 1) add a few messages in SmalltalkImage (vm ^self) 2) refactor users of SmalltalkImage current -> Smalltalk vm (or Smalltalk commandLine or...) This is the compatibility layer which will enable cross fork compatibility PART III - Provide cross fork compatibility layers: simple, Cuis and Pharo and Squeak3.8 and... just have to respond to Smalltalk vm (and a few others) either ^self or ^SmalltalkImage current or whatever they prefer PART IV - deeper refactorings 1) split SmalltalkImage at will (no precipitation good Rationale SHALL be provided). 2) introduce other Smalltalk hooks for not so well known classes (SystemNavigation / SourceFiles etc...) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SmalltalkImage current vs Smalltalk : plan B
|
|
On 3/3/2010 3:30 PM, Nicolas Cellier wrote:
> For now, plan A has more votes than plan B. > plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. > Let SmalltalkImage current ^Smalltalk for crossfork compatibility > plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = > SystemDictionary. Just to be clear: My option #2 only goes until here. I'd like to make some actual progress in the near term and your proposal is quite a bit of mid- or long-term stuff. > Advantages of plan B I see for the future: > - cleaner separation of concerns > - less vulnerable to refactoring (thanks to messages indirection) > - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) > easier thru messages Unfortunately that's all pretty much conjecture or even plain wrong. Cleaner separation of concerns is a claim. It's actually *just* the claim that was made about SmalltalkImage current and see where that has gotten us. So let's try to be careful claiming victory before things have even started. Less vulnerability to refactoring won't be happening this way either - it's no less vulnerable to get a DNU than it is to get an Undeclared. The same goes for the compatibility claim. The *real* gain regarding refactoring and compatibility will be by restoring Smalltalk as the facade that receives those various messages and then passes them on to whatever the actual implementation site is. Basically we need to be promising that we'll support Smalltalk as a facade for all the stuff that SystemDictionary/SmalltalkImage support today, but that we won't promise where it'll be implemented in the backend. This way we have room to experiment with various locations and anyone who needs the compatibility knows there is a safe, idiomatic way of doing all this stuff via Smalltalk. The people who want to experiment can do that and we can see what we like and dislike. In other words, there needs to be a very clearly cut line: If you need compatibility, you use e.g., Smalltalk allClasses, Smalltalk vmParameters, Smalltalk garbageCollect. If you don't, you're free to use Namespace default allClasses or VirtualMachine current parameters or System soleInstance garbageCollect or Smalltalk vm parameters or Smalltalk namespace allClasses. All of these can be delegated trivially to from the Smalltalk facade making it very easy to provide the necessary level of compatibility while leaving room for innovation. Cheers, - Andreas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SmalltalkImage current vs Smalltalk : plan B
|
|
In reply to this post by Nicolas Cellier
I like plan B.
at the end I would like to have. Marcus came back from germany and we will discuss. Smalltalk -> sole instance of System (aka SmalltalkImage) SystemDictionary -> renamed into Namespace and it accessible via Smalltalk environment Smalltalk namespace Or Smalltalk is just an holder for a couple of globals Smalltalk image -> SmalltalkImage current Smalltalk vm -> SmalltalkVM (not yet done) Smalltalk namespace -> Namespace instance If you want to help we can start going in that direction. I decided that I will not rant about the past anymore because I want new and POSITIVE energy. Now just a bit of knowledge of the past is still good. For new guys in the community, just imagine that SpaceTally was defined in SystemDictionary. Yes! too Similarly Smalltalk spaceTally vs SpaceTally new Smalltalk currentChangeset vs. Changeset current Smalltalk pointersTo: C vs PointerFinder pointersTo: C Smalltalk browserAllCallsOn: vs Finder/SystemNavigation browserAllCallsOn: Take scratch and you will see how it was in 2.8 :) So I believe that "Abstraction is a Good Thing" (TM) I spent far too many hours arguing in the past. Now we will make it the way we believe it is beautiful and people that do not like it are not forced to use Pharo. Stef On Mar 4, 2010, at 12:30 AM, Nicolas Cellier wrote: > For now, plan A has more votes than plan B. > plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. > Let SmalltalkImage current ^Smalltalk for crossfork compatibility > plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = > SystemDictionary. > Use messages indirections like: > Smalltalk vm imagePath > Smalltalk commandLine optionAt: 2. > etc... (see previous thread) > > At 1st step, they are not much different: > both unify Smalltalk and SmalltalkImage current API. > > Also Plan A is much simpler, thus attractive. But: > - Plan A is essentially coming back to 3.8 statu quo. > - Plan B is essentially introducing message indirections > > Advantages of plan B I see for the future: > - cleaner separation of concerns > - less vulnerable to refactoring (thanks to messages indirection) > - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) > easier thru messages > > Last, I do not desesperate to sell plan B to other forks. > See the outline pf plan B below. > > So do you still buy plan A ? > > Nicolas > > > ------------------------------------------ > OUTLINE OF PLAN B : > ------------------------------------------ > > PART I - Fusion of the 2 APIs in 1 > 1) add a globals instance variable to SmalltalkImage > 2) initialize this instance variable SmalltalkImage current globals: Smalltalk > 3) implement SystemDictionary methods in use to SmalltalkImage, and > redirect them through globals > MessageSentToGlobalFinder testMessagesSentToSmalltalk may help > 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. > > PART II - Refactoring > 1) add a few messages in SmalltalkImage (vm ^self) > 2) refactor users of SmalltalkImage current -> Smalltalk vm (or > Smalltalk commandLine or...) > This is the compatibility layer which will enable cross fork compatibility > > PART III - Provide cross fork compatibility layers: > simple, Cuis and Pharo and Squeak3.8 and... just have to respond to > Smalltalk vm (and a few others) > either ^self or ^SmalltalkImage current or whatever they prefer > > PART IV - deeper refactorings > 1) split SmalltalkImage at will (no precipitation good Rationale SHALL > be provided). > 2) introduce other Smalltalk hooks for not so well known classes > (SystemNavigation / SourceFiles etc...) > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SmalltalkImage current vs Smalltalk : plan B
|
|
On 3/4/2010 12:03 AM, Stéphane Ducasse wrote:
> I like plan B. > at the end I would like to have. Marcus came back from germany and we will discuss. > > Smalltalk -> sole instance of System (aka SmalltalkImage) > > SystemDictionary -> renamed into Namespace > and it accessible via > Smalltalk environment > Smalltalk namespace > > Or Smalltalk is just an holder for a couple of globals > Smalltalk image -> SmalltalkImage current > Smalltalk vm -> SmalltalkVM (not yet done) > Smalltalk namespace -> Namespace instance > > If you want to help we can start going in that direction. > > I decided that I will not rant about the past anymore because I want new and POSITIVE energy. > Now just a bit of knowledge of the past is still good. Indeed. Time for some more context: The only portion of that work that has ever been criticized as overly zealous was the abomination named "SmalltalkImage current". You've done lots of useful things but SmalltalkImage was unmotivated and pointless because contrary to the other changes it never encapsulated any useful domain, was verbose just for the purpose of being verbose and caused more problems than it could ever hope to solve. We'll be all better off without it. The changes done for SpaceTally, ChangeSet, PointerFinder, even SystemNavigation *did* cover useful domains and were consequently never debated. It would be good if you remembered the things that were accepted along with the things that caused discussions because it might help you to restore a more balanced view of the Squeak community. Cheers, - Andreas > For new guys in the community, just imagine that SpaceTally was defined in SystemDictionary. Yes! too > > Similarly > Smalltalk spaceTally > vs > SpaceTally new > > Smalltalk currentChangeset > vs. Changeset current > > Smalltalk pointersTo: C > vs PointerFinder pointersTo: C > > Smalltalk browserAllCallsOn: > vs > Finder/SystemNavigation browserAllCallsOn: > > Take scratch and you will see how it was in 2.8 :) > > So I believe that "Abstraction is a Good Thing" (TM) > > I spent far too many hours arguing in the past. Now we will make it the way we believe it is beautiful and > people that do not like it are not forced to use Pharo. > > Stef > > > On Mar 4, 2010, at 12:30 AM, Nicolas Cellier wrote: > >> For now, plan A has more votes than plan B. >> plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. >> Let SmalltalkImage current ^Smalltalk for crossfork compatibility >> plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = >> SystemDictionary. >> Use messages indirections like: >> Smalltalk vm imagePath >> Smalltalk commandLine optionAt: 2. >> etc... (see previous thread) >> >> At 1st step, they are not much different: >> both unify Smalltalk and SmalltalkImage current API. >> >> Also Plan A is much simpler, thus attractive. But: >> - Plan A is essentially coming back to 3.8 statu quo. >> - Plan B is essentially introducing message indirections >> >> Advantages of plan B I see for the future: >> - cleaner separation of concerns >> - less vulnerable to refactoring (thanks to messages indirection) >> - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) >> easier thru messages >> >> Last, I do not desesperate to sell plan B to other forks. >> See the outline pf plan B below. >> >> So do you still buy plan A ? >> >> Nicolas >> >> >> ------------------------------------------ >> OUTLINE OF PLAN B : >> ------------------------------------------ >> >> PART I - Fusion of the 2 APIs in 1 >> 1) add a globals instance variable to SmalltalkImage >> 2) initialize this instance variable SmalltalkImage current globals: Smalltalk >> 3) implement SystemDictionary methods in use to SmalltalkImage, and >> redirect them through globals >> MessageSentToGlobalFinder testMessagesSentToSmalltalk may help >> 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. >> >> PART II - Refactoring >> 1) add a few messages in SmalltalkImage (vm ^self) >> 2) refactor users of SmalltalkImage current -> Smalltalk vm (or >> Smalltalk commandLine or...) >> This is the compatibility layer which will enable cross fork compatibility >> >> PART III - Provide cross fork compatibility layers: >> simple, Cuis and Pharo and Squeak3.8 and... just have to respond to >> Smalltalk vm (and a few others) >> either ^self or ^SmalltalkImage current or whatever they prefer >> >> PART IV - deeper refactorings >> 1) split SmalltalkImage at will (no precipitation good Rationale SHALL >> be provided). >> 2) introduce other Smalltalk hooks for not so well known classes >> (SystemNavigation / SourceFiles etc...) >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project-bM+ny+RY8h+a+bCvCPl5/[hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SmalltalkImage current vs Smalltalk : plan B
|
|
since this is one of this rare moment in life (I rarely hear that we did something good) I want to say that this is good
to know that we did a good job in 95% of the case because after a while we only get the bad signal and now I'm spending time on pharo to build something cool and positive. :) And as I said I was never happy with the solution for smalltalkImage but I hated the put everything in SystemDictionary and I would be happy to fix but I cannot be the driver here. Stef >> If you want to help we can start going in that direction. >> >> I decided that I will not rant about the past anymore because I want new and POSITIVE energy. >> Now just a bit of knowledge of the past is still good. > > Indeed. Time for some more context: The only portion of that work that > has ever been criticized as overly zealous was the abomination named > "SmalltalkImage current". You've done lots of useful things but > SmalltalkImage was unmotivated and pointless because contrary to the > other changes it never encapsulated any useful domain, was verbose just > for the purpose of being verbose and caused more problems than it could > ever hope to solve. We'll be all better off without it. > > The changes done for SpaceTally, ChangeSet, PointerFinder, even > SystemNavigation *did* cover useful domains and were consequently never > debated. It would be good if you remembered the things that were > accepted along with the things that caused discussions because it might > help you to restore a more balanced view of the Squeak community. > > Cheers, > - Andreas > >> For new guys in the community, just imagine that SpaceTally was defined in SystemDictionary. Yes! too >> >> Similarly >> Smalltalk spaceTally >> vs >> SpaceTally new >> >> Smalltalk currentChangeset >> vs. Changeset current >> >> Smalltalk pointersTo: C >> vs PointerFinder pointersTo: C >> >> Smalltalk browserAllCallsOn: >> vs >> Finder/SystemNavigation browserAllCallsOn: >> >> Take scratch and you will see how it was in 2.8 :) >> >> So I believe that "Abstraction is a Good Thing" (TM) >> >> I spent far too many hours arguing in the past. Now we will make it the way we believe it is beautiful and >> people that do not like it are not forced to use Pharo. >> >> Stef >> >> >> On Mar 4, 2010, at 12:30 AM, Nicolas Cellier wrote: >> >>> For now, plan A has more votes than plan B. >>> plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. >>> Let SmalltalkImage current ^Smalltalk for crossfork compatibility >>> plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = >>> SystemDictionary. >>> Use messages indirections like: >>> Smalltalk vm imagePath >>> Smalltalk commandLine optionAt: 2. >>> etc... (see previous thread) >>> >>> At 1st step, they are not much different: >>> both unify Smalltalk and SmalltalkImage current API. >>> >>> Also Plan A is much simpler, thus attractive. But: >>> - Plan A is essentially coming back to 3.8 statu quo. >>> - Plan B is essentially introducing message indirections >>> >>> Advantages of plan B I see for the future: >>> - cleaner separation of concerns >>> - less vulnerable to refactoring (thanks to messages indirection) >>> - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) >>> easier thru messages >>> >>> Last, I do not desesperate to sell plan B to other forks. >>> See the outline pf plan B below. >>> >>> So do you still buy plan A ? >>> >>> Nicolas >>> >>> >>> ------------------------------------------ >>> OUTLINE OF PLAN B : >>> ------------------------------------------ >>> >>> PART I - Fusion of the 2 APIs in 1 >>> 1) add a globals instance variable to SmalltalkImage >>> 2) initialize this instance variable SmalltalkImage current globals: Smalltalk >>> 3) implement SystemDictionary methods in use to SmalltalkImage, and >>> redirect them through globals >>> MessageSentToGlobalFinder testMessagesSentToSmalltalk may help >>> 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. >>> >>> PART II - Refactoring >>> 1) add a few messages in SmalltalkImage (vm ^self) >>> 2) refactor users of SmalltalkImage current -> Smalltalk vm (or >>> Smalltalk commandLine or...) >>> This is the compatibility layer which will enable cross fork compatibility >>> >>> PART III - Provide cross fork compatibility layers: >>> simple, Cuis and Pharo and Squeak3.8 and... just have to respond to >>> Smalltalk vm (and a few others) >>> either ^self or ^SmalltalkImage current or whatever they prefer >>> >>> PART IV - deeper refactorings >>> 1) split SmalltalkImage at will (no precipitation good Rationale SHALL >>> be provided). >>> 2) introduce other Smalltalk hooks for not so well known classes >>> (SystemNavigation / SourceFiles etc...) >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project-bM+ny+RY8h+a+bCvCPl5/[hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |