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
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
