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