[squeak-dev] SmalltalkImage current vs Smalltalk : plan B

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Mar 3 23:30:54 UTC 2010


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...)



More information about the Squeak-dev mailing list