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/gCzwTLBPCX0@public.gmane.org http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project