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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project