Sorry to open a new thread, but here is my own position.
Cheers Nicolas ---------- Forwarded message ---------- From: Nicolas Cellier <[hidden email]> Date: 2010/3/3 Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk To: The general-purpose Squeak developers list <[hidden email]> 2010/3/3 Andreas Raab <[hidden email]>: > On 3/2/2010 10:14 PM, Michael Haupt wrote: >> >> Hi, >> >> Am 03.03.2010 um 03:41 schrieb Andreas Raab <[hidden email]>: >>> >>> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 <[hidden email]> > Date: 2010/3/3 > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > To: The general-purpose Squeak developers list > <[hidden email]> > > > 2010/3/3 Andreas Raab <[hidden email]>: > >> On 3/2/2010 10:14 PM, Michael Haupt wrote: >> >>> Hi, >>> >>> Am 03.03.2010 um 03:41 schrieb Andreas Raab <[hidden email]>: >>> >>>> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Nicolas Cellier
Yes I like it even if this looks like more work.
After we can write Smalltalk system vmPath Smalltalk namespace allClasses + at: -> forward to namespace before been deprecated > Sorry to open a new thread, but here is my own position. > > Cheers > > Nicolas > > ---------- Forwarded message ---------- > From: Nicolas Cellier <[hidden email]> > Date: 2010/3/3 > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > To: The general-purpose Squeak developers list > <[hidden email]> > > > 2010/3/3 Andreas Raab <[hidden email]>: >> On 3/2/2010 10:14 PM, Michael Haupt wrote: >>> >>> Hi, >>> >>> Am 03.03.2010 um 03:41 schrieb Andreas Raab <[hidden email]>: >>>> >>>> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |