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 <nicolas.cellier.aka.nice@gmail.com> Date: 2010/3/3 Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/3 Andreas Raab <andreas.raab@gmx.de>:
On 3/2/2010 10:14 PM, Michael Haupt wrote:
Hi,
Am 03.03.2010 um 03:41 schrieb Andreas Raab <andreas.raab@gmx.de>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project