I'd vote for b) too, should make it easier than a) in the future to move towards a separation of concerns like what was discussed.
Personally, I think some of the voters might be a bit mislead by the points "compatible with Cuis" for a), and "different from Cuis" for b, listed in the initial post. Option b) is still _compatible_ with Cuis, only the _implementation_ is different. (ie code like Smalltalk vmParameterAt: xyz will work with both proposed solutions). Unless, of course, I'm the one misunderstanding :) Cheers, Henry Den 03.03.2010 15:02, skrev Nicolas Cellier: > Sorry to open a new thread, but here is my own position. > > Cheers > > Nicolas > > ---------- Forwarded message ---------- > From: Nicolas Cellier <[email protected]> > Date: 2010/3/3 > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > To: The general-purpose Squeak developers list > <[email protected]> > > > 2010/3/3 Andreas Raab <[email protected]>: > >> On 3/2/2010 10:14 PM, Michael Haupt wrote: >> >>> Hi, >>> >>> Am 03.03.2010 um 03:41 schrieb Andreas Raab <[email protected]>: >>> >>>> Consequently I'm going to completely ignore any forward-looking >>>> proposals and simply state that the current count is 3 votes for the >>>> first variant (Phil, David, Bert) and 1 vote for the second variant >>>> (Igor). >>>> >>> here's another for "Smalltalk", then. >>> >> That choice doesn't exist :-) You can vote for: >> >> a) Smalltalk class == SystemDictionary, or >> >> b) Smalltalk class == SmalltalkImage >> >> Cheers, >> - Andreas >> >> >> > I vote for b). > > After discussing this with Stephane Ducasse, I quite agree on this scheme: > > SmalltalkImage should better be renamed System. > System soleInstance = Smalltalk. > Of course an optional bakward compatibility module would define > SmalltalkImage current > > Smalltalk globals or Smalltalk namespace class = SystemDictionary > Maybe SystemDictionary shouldbetter be renamed Namespace to separate > the notion of System. > > Then, if we are in need of separating methods, create new classes > SmalltalkVM etc... > But don't impose that in Kernel code, use methods indirections > (Smalltalk vm blah...) > > This is a bit harder path than a), but lot cleaner IMO > > Nicolas > > _______________________________________________ > 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
