[Pharo-project] Worth reading discussion on Smalltalk vs SmalltalkImage

March 3, 2010

      Browser vs SystemNavigation and much more such as abstraction (traits kind of mistakes) for the sake of it.

I was thinking that I would love to have a message-oriented solution.
One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage current.
The mail is long but worth to get some ideas that you may like or not.

Stef

Begin forwarded message:
...
From: Andreas Raab <andreas.raab@gmx.de>
Date: March 2, 2010 5:08:56 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Folks -
I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
  Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 10:56:03 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/2 keith <keith_hodges@yahoo.co.uk>:
...
Smalltalk host windowSystem
Smalltalk host platformName
Smalltalk host osVersion
Smalltalk commandLine vmPath.
Smalltalk commandLine imagePath.
Smalltalk commandLine documentPath.
Smalltalk commandLine optionNumber: 2.
Smalltalk commandLine optionAt: 2.
Not every protocol has to be implemented by a different class.
I asked earlier about a name for the StartupManager. StartupManager would
happily handle #commandLine and probably #host as well.
Keith
Sure, implementation detail.
Quite sure Squeak/Cuis/Pharo/... wouldhave different implementations.
Nicolas
...
Begin forwarded message:
...
From: Igor Stasenko <siguctua@gmail.com>
Date: March 2, 2010 11:00:26 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
So, looks like we having a good consensus?
/me always happy when it happens :)
On 2 March 2010 23:56, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
2010/3/2 keith <keith_hodges@yahoo.co.uk>:
...
Smalltalk host windowSystem
Smalltalk host platformName
Smalltalk host osVersion
Smalltalk commandLine vmPath.
Smalltalk commandLine imagePath.
Smalltalk commandLine documentPath.
Smalltalk commandLine optionNumber: 2.
Smalltalk commandLine optionAt: 2.
Not every protocol has to be implemented by a different class.
I asked earlier about a name for the StartupManager. StartupManager would
happily handle #commandLine and probably #host as well.
Keith
Sure, implementation detail.
Quite sure Squeak/Cuis/Pharo/... wouldhave different implementations.
Nicolas
...
-- 
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: Igor Stasenko <siguctua@gmail.com>
Date: March 2, 2010 11:10:29 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Haha..
i just recalled that i proposed something like this before.
Here it is:
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg02869.htm...
-- 
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: Andreas Raab <andreas.raab@gmx.de>
Date: March 3, 2010 3:41:22 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Folks -
That response was most definitely not what I had expected :-) I thought this was going to be a quick round of -1 or +1 instead lots of discussions about interesting forward-looking issues.
However, what I'm after in this round is not "how to make things better" but rather how to most effectively undo what got broken before. The current separation into SystemDictionary and SmalltalkImage is unmotivated and pointless. However, regardless of what we may end up in the future there is no doubt that there's a *lot* of code out there that will be using either Smalltalk or SmalltalkImage current. This is the problem that I'm trying to address here, no more, no less.
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). This isn't the final tally but if you care about the compatibility issues raised here please be specific and state your preference for the options listed below rather than making another forward-looking proposal that I have no intention to implement for this round.
Cheers,
 - Andreas
On 3/1/2010 8:08 PM, Andreas Raab wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten
by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it
now. The only question is which way. There are two alternatives which
achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary;
implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the
mess we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
- Andreas
Begin forwarded message:
...
From: Andreas Raab <andreas.raab@gmx.de>
Date: March 3, 2010 3:45:10 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 3/2/2010 9:04 AM, Eliot Miranda wrote:
...
The worst thing going on with things like SmalltalkImage current,
SystemNavigation default and traits is the introduction of abstraction
for its own sake.  Abstraction is properly used to manage complexity.
 But for example, as others have pointed out, there is no other image
than the current image and so SmalltalkImage current is merely verbiage.
 And yet SourceFiles is an obvious area which could use a lot more
features (being able to load package sources without appending them to
the sources file, or having two changes files, one for loaded packages,
one for user modifications, etc).
Thanks Eliot. That's an *excellent* description of the problem.
Cheers,
 - Andreas
Begin forwarded message:
...
From: keith <keith_hodges@yahoo.co.uk>
Date: March 3, 2010 4:15:51 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 3 Mar 2010, at 02:45, Andreas Raab wrote:
...
On 3/2/2010 9:04 AM, Eliot Miranda wrote:
...
The worst thing going on with things like SmalltalkImage current,
SystemNavigation default and traits is the introduction of abstraction
for its own sake.  Abstraction is properly used to manage complexity.
 But for example, as others have pointed out, there is no other image
than the current image and so SmalltalkImage current is merely verbiage.
 And yet SourceFiles is an obvious area which could use a lot more
features (being able to load package sources without appending them to
the sources file, or having two changes files, one for loaded packages,
one for user modifications, etc).
Thanks Eliot. That's an *excellent* description of the problem.
Cheers,
 - Andreas
And option 3 dnu handler on smalltalk.
I think that my vote would be for option 1, and cuis compatibility. Regrouping, before breaking things out again, 
but lets start using the new accessors as well.
I implemented some in cuis
#host #organization #query #sourceCode #vm #commandLine #startupManager
However isn't the dnu solution is the only one that will be able to cope in the longer term if you do break things out again. 
So one could argue that you may as well use it now.
Keith
Begin forwarded message:
...
From: Andreas Raab <andreas.raab@gmx.de>
Date: March 3, 2010 5:01:05 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 3/2/2010 7:21 PM, Ronald Spengler wrote:
...
Well heck:) I don't think my opinion is of a lot of value here, but
aesthetically I'd like to see SmalltalkImage killed. Partly I'm just
not clear on what concerns it really separates.
The dictionary and the name aspect. Option #2 has the effect that Smalltalk is-no-longer-a Dictionary. I do find that an improvement; subclassing the collection classes by something that's not really a collection (in this case SystemDictionary is a representative of the Smalltalk environment with very few dictionary aspects) isn't particularly good design. Plus I find it a bit problematic that in option #1 Smalltalk is an instance of SystemDictionary and SmalltalkImage is a class that has no relationship to the Smalltalk image.
Cheers,
 - Andreas
...
On Tuesday, March 2, 2010, Andreas Raab<andreas.raab@gmx.de>  wrote:
...
On 3/2/2010 9:04 AM, Eliot Miranda wrote:
The worst thing going on with things like SmalltalkImage current,
SystemNavigation default and traits is the introduction of abstraction
for its own sake.  Abstraction is properly used to manage complexity.
  But for example, as others have pointed out, there is no other image
than the current image and so SmalltalkImage current is merely verbiage.
  And yet SourceFiles is an obvious area which could use a lot more
features (being able to load package sources without appending them to
the sources file, or having two changes files, one for loaded packages,
one for user modifications, etc).
Thanks Eliot. That's an *excellent* description of the problem.
Cheers,
  - Andreas
Begin forwarded message:
...
From: Michael Haupt <mhaupt@gmail.com>
Date: March 3, 2010 7:14:27 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
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.
Best,
Michael
Begin forwarded message:
...
From: Andreas Raab <andreas.raab@gmx.de>
Date: March 3, 2010 7:38:12 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
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
Begin forwarded message:
...
From: Michael Haupt <mhaupt@gmail.com>
Date: March 3, 2010 8:57:02 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Hi again,
On Wed, Mar 3, 2010 at 7:38 AM, Andreas Raab <andreas.raab@gmx.de> wrote:
...
...
here's another for "Smalltalk", then.
That choice doesn't exist :-) You can vote for:
a) Smalltalk class == SystemDictionary, or
b) Smalltalk class == SmalltalkImage
ach yuck. Sorry, I meant #1. :-)
Early morning syndrome.
Best,
Michael
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 10:05:13 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/2 Bert Freudenberg <bert@freudenbergs.de>:
...
On 02.03.2010, at 05:08, Andreas Raab wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
      Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
1) +1
2) -0
- Bert -
I won't propose anything here.
Just invite to think of it.
As noticed by Ronald, the main problem with SmalltalkImage is that it
does not represent any Object indeed...
It's just a place holder for some system utilities...
When I see idioms like (SmalltalkImage current vmParameterAt:
parameterIndex), I just wonder why not (SmalltalkVM current
parameterAt: parameterIndex)....
If the VM where reified anyway, I would as well understand (Smalltalk
vm parameterAt: parameterIndex).
Sure, Marcus & Steph were right: why the hell a SystemDictionary
should know about the image file name or some vm parameter ?
Except that Smalltalk was not only a SystemDictionary but the
interface to "System" parameters fora very long time (st80)...
And as we can see under vmParameter idiom light, SmalltalkImage is
arbitrary. At least as arbitrary as Smalltalk.
Just less readable, adding an unnecessary current complexification...
Yes, current is just meaningless indeed until you start playing with
some sort of hydra VM and gain access to an external image (a frozen
ObjectMemory, or its Image file dump).
In the interim, a global named #System  would have been far better
understood (or #Squeak if we don't want to be portable across forks)
That's where Stephane and Marcus failed...
... replacing a well known hack (Smalltalk == System) with something
not solid enough.
When you break such habits (and code) you have to sell it with well
thought replacement.
Though, when I see code like (Smalltalk cleanUpUndoCommands), I can't
help thinking Steph and Marcus intention was right...
Nicolas
Begin forwarded message:
...
From: StÃ©phane Rollandin <lecteur@zogotounga.net>
Date: March 2, 2010 1:18:55 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
...
As noticed by Ronald, the main problem with SmalltalkImage is that it
does not represent any Object indeed...
It represent some meta-information about the Smalltalk system, aspects of the system seen from outside so to say. It can not really be an object semantically on par with the others, but that information must be provided somehow.
AFAIC I see no actual problem here, better a question of taste concerning where the meta-info should be stored and how it should be retrieved.
...
Though, when I see code like (Smalltalk cleanUpUndoCommands), ...
That's the user (that is, the outside) ordering the system to do something. It fits in my view of what SmalltalkImage represents.
Concerning Andreas question, I would keep globals in Smalltalk (since it is the SystemDictionary) and put everything else in SmalltalkImage that I would rename Squeak because it's nicer (and also because the image is only a part of the system, along with the VM for example).
Or we could just reify everything, and have classes Image, Changes, Sources, VM, Platform, User... why not ? we already have DisplayScreen ("There is only one instance of me, Display. It is a global and is used to handle general user requests to deal with the whole display screen."). It could be fun.
my 2 cents...
Stef
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 4:41:52 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/2 StÃ©phane Rollandin <lecteur@zogotounga.net>:
...
...
As noticed by Ronald, the main problem with SmalltalkImage is that it
does not represent any Object indeed...
It represent some meta-information about the Smalltalk system, aspects of
the system seen from outside so to say. It can not really be an object
semantically on par with the others, but that information must be provided
somehow.
Hehe, I notice you used this idiom (Smalltalk system), rather than
this one (SmalltalkImage current).
This is not neutral :)
I would prefer the former too ;)
See for example, Dolphin has:
Smalltalk developmentSystem -> a SmalltalkSystem
Could they have a Smalltalk deploymentSystem ?
In the same time, they have a rather clean SystemDictionary.
VW, with namespace changes completely cleaned Smalltalk too (it's just
a NameSpace).
Utilities are spreaded around a bunch of classes (apart Smalltalk
version for portability).
Personnally, I was bred with st80 (Browser browse...), not those
(SystemNavigation default browse...) and it sometimes still bugs me ;)
...
...
AFAIC I see no actual problem here, better a question of taste concerning
where the meta-info should be stored and how it should be retrieved.
...
Though, when I see code like (Smalltalk cleanUpUndoCommands), ...
That's the user (that is, the outside) ordering the system to do something.
It fits in my view of what SmalltalkImage represents.
Concerning Andreas question, I would keep globals in Smalltalk (since it is
the SystemDictionary) and put everything else in SmalltalkImage that I would
rename Squeak because it's nicer (and also because the image is only a part
of the system, along with the VM for example).
Or we could just reify everything, and have classes Image, Changes, Sources,
VM, Platform, User... why not ? we already have DisplayScreen ("There is
only one instance of me, Display. It is a global and is used to handle
general user requests to deal with the whole display screen."). It could be
fun.
As I said, (Smalltalk vm parameterAt: ) would not shock me.
Of course, replace first all these (vmParameterAt:
obscureCodeForGurus) by more explicit message ;)
What idiom do we have in use by now ?
- The globals:
Smalltalk keys sort reject: [:e | (Smalltalk at: e) isBehavior]
#(#ActiveEvent #ActiveHand #ActiveWorld #CustomEventsRegistry
#Display #ImageImports #Processor #References #ScheduledControllers
#ScriptingSystem #Sensor #Smalltalk #SourceFiles #SystemOrganization
#TextConstants #Transcript #Undeclared #World)
- (SomeClass current)
(Smalltalk classNames asArray sort select: [:e | (Smalltalk at: e)
class includesSelector: #current])
#(#BitBlt #CPUWatcher #ChangeSet #ColorTheme #Locale #LocaleID
#NaturalLanguageTranslator #Project #ReleaseBuilderFor3dot10
#ResourceCollector #ServiceRegistry #SmalltalkImage #SystemVersion
#TestResource #WarpBlt)
I omit #( #DateAndTime  #Time #TimeStamp #Timespan  #Year )
- (SomeClass default)
(Smalltalk classNames asArray sort select: [:e | (Smalltalk at: e)
class includesSelector: #default])
#(#AbstractSound #AppRegistry #Beeper #BorderStyle #Categorizer
#Clipboard #FMSound #FileDirectory #FontChooserTool #HTTPLoader
#Imports #InputSensor #InstallerUniverse #MCCacheRepository
#MCRepositoryGroup #NaturalLanguageTranslator #PackageInfo
#PackageOrganizer #PluckedSound #Requestor #SMSqueakMap
#SecurityManager #SystemNavigation #TTCFontDescription
#TTFontDescription #TextConverter #TextStyle #TimeZone #ToolBuilder
#UIManager #UUIDGenerator #UnloadedSound #WeakRegistry)
Nobody would bring back all corresponding methods in SystemDictionary
I presume...
Nicolas
...
my 2 cents...
Stef
Begin forwarded message:
...
From: "David T. Lewis" <lewis@mail.msen.com>
Date: March 2, 2010 5:24:18 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On Mon, Mar 01, 2010 at 08:08:56PM -0800, Andreas Raab wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten 
by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it 
now. The only question is which way. There are two alternatives which 
achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; 
implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to 
SmalltalkImage; add a 'globals' variable (populated by an instance of 
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
  Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I favor #1.
Rationale:
The name "SmalltalkImage" sounds like it means something, but I can't
figure out what. Based on the things that it actually implements, I
can't think of any definition that would make sense. The class comment
is meaningless and adds to the confusion.
I honestly can't think of any way to fix "SmalltalkImage" that does
not introduce more incompatibilities, so that leaves the Cuis approach
as my preference.
I do think it may be worth waiting a week or so to see if anyone can
come up with any better approach that meets these criteria:
- Moves the extraneous behavior out of SystemDictionary, as per the
  original intent of the SmalltalkImage refactoring.
- Consists only of classes with meaningful class comments and
  clear responsibilities 
- Preserves "SmalltalkImage current == Smalltalk" for compatibility
- Preserves the "SmalltalkImage current" idiom for compatibility
I cannot personally think of any good way to do this, but maybe someone
else can.
Dave
Begin forwarded message:
...
From: "David T. Lewis" <lewis@mail.msen.com>
Date: March 2, 2010 5:27:24 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On Tue, Mar 02, 2010 at 10:05:13AM +0100, Nicolas Cellier wrote:
...
Though, when I see code like (Smalltalk cleanUpUndoCommands), I can't
help thinking Steph and Marcus intention was right...
Well, it's a utility procedure, so "Utilities cleanUpUndoCommands" comes
to mind.
Dave
Begin forwarded message:
...
From: Chris Muller <asqueaker@gmail.com>
Date: March 2, 2010 5:32:34 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: ma.chris.m@gmail.com, The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab <andreas.raab@gmx.de> wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now.
The only question is which way. There are two alternatives which achieve the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
Begin forwarded message:
...
From: Igor Stasenko <siguctua@gmail.com>
Date: March 2, 2010 5:55:10 PM GMT+01:00
To: ma.chris.m@gmail.com, The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
If you remember previous discussion about this, i proposed to use
Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
so, that Smalltalk>>at: x
implemented as
 globals at: x
then Smalltalk global is an instance of SmalltalkImage , equal to
SmalltalkImage current.
And SystemDictionary is just a dictionary without any extra utility methods.
On 2 March 2010 18:32, Chris Muller <asqueaker@gmail.com> wrote:
...
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab <andreas.raab@gmx.de> wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now.
The only question is which way. There are two alternatives which achieve the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
-- 
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: Ronald Spengler <ron.spengler@gmail.com>
Date: March 3, 2010 4:21:26 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Well heck:) I don't think my opinion is of a lot of value here, but
aesthetically I'd like to see SmalltalkImage killed. Partly I'm just
not clear on what concerns it really separates.
On Tuesday, March 2, 2010, Andreas Raab <andreas.raab@gmx.de> wrote:
...
On 3/2/2010 9:04 AM, Eliot Miranda wrote:
The worst thing going on with things like SmalltalkImage current,
SystemNavigation default and traits is the introduction of abstraction
for its own sake.  Abstraction is properly used to manage complexity.
 But for example, as others have pointed out, there is no other image
than the current image and so SmalltalkImage current is merely verbiage.
 And yet SourceFiles is an obvious area which could use a lot more
features (being able to load package sources without appending them to
the sources file, or having two changes files, one for loaded packages,
one for user modifications, etc).
Thanks Eliot. That's an *excellent* description of the problem.
Cheers,
 - Andreas
-- 
Ron
Begin forwarded message:
...
From: Alexander LazareviÄ <laza@blobworks.com>
Date: March 3, 2010 4:26:22 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
1) +1
On Tue, Mar 2, 2010 at 05:08, Andreas Raab <andreas.raab@gmx.de> wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now.
The only question is which way. There are two alternatives which achieve the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
Begin forwarded message:
...
From: Eliot Miranda <eliot.miranda@gmail.com>
Date: March 2, 2010 9:41:35 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/3/2 Eliot Miranda <eliot.miranda@gmail.com>:
...
On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges@yahoo.co.uk> wrote:
...
1) The Cuis variant: Move all the code back to SystemDictionary; implement
SmalltalkImage current as ^Smalltalk.
Cuis didn't exactly move the code back to SystemDictionary, of course it
never left in the first place. It is easier for Cuis to implement
compatibility with "trunk" than it is for "trunk" to go back to the old way.
How much code uses Smalltalk at: ? As soon as you put SmalltalkImage
current into Smalltalk you have to make what was an "image utilities" class
behave like a dictionary.
You seem to be saying, we must have a single place to access this stuff
called "Smalltalk". I think what really needs to happen is to factor things
up nicely and logically so we know where to find things and can write
compatible code.
I propose as a starting point, that we design a scheme or convention that
implements the "long hand" variant, and then when happy with this, implement
the short hand versions. The most obvious long hand variant.
self class environment "system globals"
self class environment image
self class environment navigation
self class environment sourceFiles
self class environment startupManager.
self class environment organization.
This doesn't make sense in a workspace where the notion of the current class
is a weak one (current class is UndefinedObject for want of having no class
at all).
Why are global names worse than any of these?
I think Smalltalk == System is a good approach.  Making things verbose is a
very poor direction.  When a cluster of associated behaviours gets complex
enough then by all means move it out to a class.  So in VisualWorks the
pairing of ObjectMemory and MemoryPolicy which allows inspection and
tailoring of memory management makes sense.
A Tools object for systemNavigation might make sense, but SystemNavigation
is a poor name; long (SystemNavigation default being worse) and not very
informative.  BrowserQuery would be better.  Browse would be better.
Maybe a SystemNavigation was introduced to handle the fact that there
were many different browsers... Or Morphic + MVC....
Maybe some were thinking embedding a default + some alternatives in a
single image...
Maybe, but if that effort wasn't implemented it wass pointless.  Introducing the abstraction without adding it is pointless.  For example, using traits only in the traits implementation, instead of where it belongs, the collection hierarchy, is pointless.
But I'm not criticising the idea of SystemNavigation, only its naming.  There's clear benefit to having something with SystemNavigation functionality, but SystemNavigation is a poor name.  Browse is a better name.
(Browser browseAllCallsOn: #yourself) was just perfectly short :)
Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we
really want to avoid pairing each message.
A pity that Browser itself failed to become the abstract factory which
SystemNavigation default is...
Yes, but Browser is a specific tool and it makes sense when there are many different browsers to separate the request to open a browser from the browser itself.  Also, queries which answer sets of MethodReferences et al are very useful and don't necessarily belong in Browser.  So why not Browse and Browser for the request and one of its results?  Is SystemNavigation default a good name?  Does the default in SystemNavigation default provide anything useful (e.g. that preferences don't)?
...
The worst thing going on with things like SmalltalkImage current,
SystemNavigation default and traits is the introduction of abstraction for
its own sake.  Abstraction is properly used to manage complexity.  But for
example, as others have pointed out, there is no other image than the
current image and so SmalltalkImage current is merely verbiage.  And yet
SourceFiles is an obvious area which could use a lot more features (being
able to load package sources without appending them to the sources file, or
having two changes files, one for loaded packages, one for user
modifications, etc).
I meant to emphasise here that traits is a perfect example of not going far enough to justify its existence.  Traits are a great idea but unless they're carried through and used in implementing class libraries other than the traits system itself (i.e. especially the collection hierarchy) they're overhead that is carried in lots of places (cognitive complexity for new users, complexity in the tools, e.g. Monticello, etc).  I'm not saying get rid of traits.  I'm saying that something shouldn't become a component of the core until it carries its weight (much as in PARC the contents of the base image were discussed every 6 months in a sort of balloon game with components that couldn't be defended being ejected) and we shouldn't repeat the mistake of integrating half-completed abstractions.  When introducing new abstractions during decomposition be sure that the effort is worth it and that the implementation is carried through.
...
Another bad thing is not thinking about names.  Names are extremely
important for making sense of a system, most especially for new users.
 Finding a vivid short name is well worth extra effort.
I'd love to see someone start a side project which comprised
- a minimal kernel image, capable of bootstrapping (so includes base class
library, compiler, gui-less debugger/back-tracer, file system interface)
- a set of packages comprising loadable programming tools
- a refactoring engine and rules base for converting from the current Squeak
dialects where the rules were renamings of things like "SystemNavigation
default" into "Browse"
and which focussed on a new set of global names for the environment.  The
base class library would stay the same, but Smalltalk, SystemNavigation,
SmalltalkImage etc would be up for grabs.
I'd then love to see a university department divide a class into two and see
how each set of students faired with each variant, each provided with
otherwise identical introductory material that differed only in the names &
organization of these system services classes.
...
For the shorter hand variants, personally I wouldn't mind these being
implemented on Object, aka #systemNavigation.
self systemEnvironment, self systemImage, self systemNavigation, self
systemSourceFiles, self systemStartupManager, self systemOrganization
but I think I would prefer an instance side implementation of
#environment/#system/#smalltalk
SmalltalkImage current would then become:
self environment image / self smalltalk image.
ok, it's not compatible, but its not a mess either.
The compatibility I would fix temporarily with better code loading tools,
or a dnu: on SystemDictionary.
K.
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 10:07:33 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/2 Eliot Miranda <eliot.miranda@gmail.com>:
...
On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
2010/3/2 Eliot Miranda <eliot.miranda@gmail.com>:
...
On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges@yahoo.co.uk> wrote:
...
1) The Cuis variant: Move all the code back to SystemDictionary;
implement
SmalltalkImage current as ^Smalltalk.
Cuis didn't exactly move the code back to SystemDictionary, of course
it
never left in the first place. It is easier for Cuis to implement
compatibility with "trunk" than it is for "trunk" to go back to the old
way.
How much code uses Smalltalk at: ? As soon as you put SmalltalkImage
current into Smalltalk you have to make what was an "image utilities"
class
behave like a dictionary.
You seem to be saying, we must have a single place to access this stuff
called "Smalltalk". I think what really needs to happen is to factor
things
up nicely and logically so we know where to find things and can write
compatible code.
I propose as a starting point, that we design a scheme or convention
that
implements the "long hand" variant, and then when happy with this,
implement
the short hand versions. The most obvious long hand variant.
self class environment "system globals"
self class environment image
self class environment navigation
self class environment sourceFiles
self class environment startupManager.
self class environment organization.
This doesn't make sense in a workspace where the notion of the current
class
is a weak one (current class is UndefinedObject for want of having no
class
at all).
Why are global names worse than any of these?
I think Smalltalk == System is a good approach.  Making things verbose
is a
very poor direction.  When a cluster of associated behaviours gets
complex
enough then by all means move it out to a class.  So in VisualWorks the
pairing of ObjectMemory and MemoryPolicy which allows inspection and
tailoring of memory management makes sense.
A Tools object for systemNavigation might make sense, but
SystemNavigation
is a poor name; long (SystemNavigation default being worse) and not very
informative.  BrowserQuery would be better.  Browse would be better.
Maybe a SystemNavigation was introduced to handle the fact that there
were many different browsers... Or Morphic + MVC....
Maybe some were thinking embedding a default + some alternatives in a
single image...
Maybe, but if that effort wasn't implemented it wass pointless.  Introducing
the abstraction without adding it is pointless.  For example, using traits
only in the traits implementation, instead of where it belongs, the
collection hierarchy, is pointless.
But I'm not criticising the idea of SystemNavigation, only its naming.
 There's clear benefit to having something with SystemNavigation
functionality, but SystemNavigation is a poor name.  Browse is a better
name.
...
(Browser browseAllCallsOn: #yourself) was just perfectly short :)
Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we
really want to avoid pairing each message.
A pity that Browser itself failed to become the abstract factory which
SystemNavigation default is...
Yes, but Browser is a specific tool and it makes sense when there are many
different browsers to separate the request to open a browser from the
browser itself. Also, queries which answer sets of MethodReferences et al
are very useful and don't necessarily belong in Browser.  So why not Browse
and Browser for the request and one of its results?  Is SystemNavigation
default a good name?  Does the default in SystemNavigation default provide
anything useful (e.g. that preferences don't)?
Agree, 99%
For the remaining 1%, my thought was that Browser could become an
abstract factory instead of a Specific tool.
The specific tools would be renamed SystemBrowser (or HierarchyBrowser
OBBrowser WhiskerBrowser etc...).
Nicolas
...
...
...
The worst thing going on with things like SmalltalkImage current,
SystemNavigation default and traits is the introduction of abstraction
for
its own sake.  Abstraction is properly used to manage complexity.  But
for
example, as others have pointed out, there is no other image than the
current image and so SmalltalkImage current is merely verbiage.  And yet
SourceFiles is an obvious area which could use a lot more features
(being
able to load package sources without appending them to the sources file,
or
having two changes files, one for loaded packages, one for user
modifications, etc).
I meant to emphasise here that traits is a perfect example of not going far
enough to justify its existence.  Traits are a great idea but unless they're
carried through and used in implementing class libraries other than the
traits system itself (i.e. especially the collection hierarchy) they're
overhead that is carried in lots of places (cognitive complexity for new
users, complexity in the tools, e.g. Monticello, etc).  I'm not saying get
rid of traits.  I'm saying that something shouldn't become a component of
the core until it carries its weight (much as in PARC the contents of the
base image were discussed every 6 months in a sort of balloon game with
components that couldn't be defended being ejected) and we shouldn't repeat
the mistake of integrating half-completed abstractions.  When introducing
new abstractions during decomposition be sure that the effort is worth it
and that the implementation is carried through.
Don't apply that on Squeak now, we gonna feel naked ;)
...
...
...
Another bad thing is not thinking about names.  Names are extremely
important for making sense of a system, most especially for new users.
 Finding a vivid short name is well worth extra effort.
I'd love to see someone start a side project which comprised
- a minimal kernel image, capable of bootstrapping (so includes base
class
library, compiler, gui-less debugger/back-tracer, file system interface)
- a set of packages comprising loadable programming tools
- a refactoring engine and rules base for converting from the current
Squeak
dialects where the rules were renamings of things like "SystemNavigation
default" into "Browse"
and which focussed on a new set of global names for the environment.
 The
base class library would stay the same, but Smalltalk, SystemNavigation,
SmalltalkImage etc would be up for grabs.
I'd then love to see a university department divide a class into two and
see
how each set of students faired with each variant, each provided with
otherwise identical introductory material that differed only in the
names &
organization of these system services classes.
...
For the shorter hand variants, personally I wouldn't mind these being
implemented on Object, aka #systemNavigation.
self systemEnvironment, self systemImage, self systemNavigation, self
systemSourceFiles, self systemStartupManager, self systemOrganization
but I think I would prefer an instance side implementation of
#environment/#system/#smalltalk
SmalltalkImage current would then become:
self environment image / self smalltalk image.
ok, it's not compatible, but its not a mess either.
The compatibility I would fix temporarily with better code loading
tools,
or a dnu: on SystemDictionary.
K.
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 10:20:34 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/2 Igor Stasenko <siguctua@gmail.com>:
...
On 2 March 2010 22:00, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
2010/3/2 Andreas Raab <andreas.raab@gmx.de>:
...
On 3/2/2010 8:55 AM, Igor Stasenko wrote:
...
If you remember previous discussion about this, i proposed to use
Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
so, that Smalltalk>>at: x
implemented as
  globals at: x
then Smalltalk global is an instance of SmalltalkImage , equal to
SmalltalkImage current.
And SystemDictionary is just a dictionary without any extra utility
methods.
This is option #2 below. (Sorry I didn't recall your post; otherwise I
would've named it the Igor variant :-)
Cheers,
 - Andreas
...
On 2 March 2010 18:32, Chris Muller<asqueaker@gmail.com>  wrote:
...
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab@gmx.de>
 wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten
by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it
now.
The only question is which way. There are two alternatives which achieve
the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary;
implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the
mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
What if instead of writing (SmalltalkImage current) you would just say
(Smalltalk vm).
Would this be tolerably short ?
Would the compatibility layer be short enough ?
Squeak 3.8: SystemDictionary>>vm ^ self
Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current
I took a look, and except source code management, a majority of
SmalltalkImage methods are related to VM and command line.
We could as well move messages to SmalltalkVM and just let a
SmalltalkImage class current hook
But I don't think it is necessary.
What do you think ?
I think we should define a distinctive roles for these parts and make
sure none of them overlap.
'vm' is for tuning/poking GC options/attributes and various
interpreter specific stuff.
'system' is for poking with host system options/attributes
'image' is for poking with language-wide (global) stuff & utils
then , for any behavior it would be clear, what entity is responsible
for it, not like currently
when you don't know what is better 'Smalltalk' or 'SmalltalkImage current'
like this ?
Smalltalk vm version
Smalltalk vm extraMemory
Smalltalk vm listLoadedModules
But then:
Smalltalk vm allocationCount
or Smalltalk memory allocationCount ?
or Smalltalk gc allocationCount ?
Smalltalk host windowSystem
Smalltalk host platformName
Smalltalk host osVersion
Smalltalk commandLine vmPath.
Smalltalk commandLine imagePath.
Smalltalk commandLine documentPath.
Smalltalk commandLine optionNumber: 2.
Smalltalk commandLine options.
Smalltalk commandLine argumentNumber: 1.
Smalltalk commandLine arguments.
Smalltalk sourceCode condenseChanges.
...
...
--
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: Igor Stasenko <siguctua@gmail.com>
Date: March 2, 2010 10:35:22 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 2 March 2010 23:20, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
2010/3/2 Igor Stasenko <siguctua@gmail.com>:
...
On 2 March 2010 22:00, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
2010/3/2 Andreas Raab <andreas.raab@gmx.de>:
...
On 3/2/2010 8:55 AM, Igor Stasenko wrote:
...
If you remember previous discussion about this, i proposed to use
Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
so, that Smalltalk>>at: x
implemented as
  globals at: x
then Smalltalk global is an instance of SmalltalkImage , equal to
SmalltalkImage current.
And SystemDictionary is just a dictionary without any extra utility
methods.
This is option #2 below. (Sorry I didn't recall your post; otherwise I
would've named it the Igor variant :-)
Cheers,
 - Andreas
...
On 2 March 2010 18:32, Chris Muller<asqueaker@gmail.com>  wrote:
...
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab@gmx.de>
 wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten
by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it
now.
The only question is which way. There are two alternatives which achieve
the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary;
implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the
mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
What if instead of writing (SmalltalkImage current) you would just say
(Smalltalk vm).
Would this be tolerably short ?
Would the compatibility layer be short enough ?
Squeak 3.8: SystemDictionary>>vm ^ self
Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current
I took a look, and except source code management, a majority of
SmalltalkImage methods are related to VM and command line.
We could as well move messages to SmalltalkVM and just let a
SmalltalkImage class current hook
But I don't think it is necessary.
What do you think ?
I think we should define a distinctive roles for these parts and make
sure none of them overlap.
'vm' is for tuning/poking GC options/attributes and various
interpreter specific stuff.
'system' is for poking with host system options/attributes
'image' is for poking with language-wide (global) stuff & utils
then , for any behavior it would be clear, what entity is responsible
for it, not like currently
when you don't know what is better 'Smalltalk' or 'SmalltalkImage current'
like this ?
yes
...
Smalltalk vm version
Smalltalk vm extraMemory
Smalltalk vm listLoadedModules
i like it much. From this code its clear what it does!
...
But then:
Smalltalk vm allocationCount
or Smalltalk memory allocationCount ?
or Smalltalk gc allocationCount ?
Depends to what level you need to decompose things:
vm includes interpreter, and gc.
...
Smalltalk host windowSystem
Smalltalk host platformName
Smalltalk host osVersion
Smalltalk commandLine vmPath.
Smalltalk commandLine imagePath.
Smalltalk commandLine documentPath.
Smalltalk commandLine optionNumber: 2.
Smalltalk commandLine optionAt: 2.
...
Smalltalk commandLine options.
Smalltalk commandLine argumentNumber: 1.
Smalltalk commandLine arguments.
Smalltalk sourceCode condenseChanges.
...
...
--
Best regards,
Igor Stasenko AKA sig.
-- 
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: Eliot Miranda <eliot.miranda@gmail.com>
Date: March 2, 2010 10:44:16 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On Tue, Mar 2, 2010 at 1:20 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/3/2 Igor Stasenko <siguctua@gmail.com>:
...
On 2 March 2010 22:00, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
2010/3/2 Andreas Raab <andreas.raab@gmx.de>:
...
On 3/2/2010 8:55 AM, Igor Stasenko wrote:
...
If you remember previous discussion about this, i proposed to use
Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
so, that Smalltalk>>at: x
implemented as
  globals at: x
then Smalltalk global is an instance of SmalltalkImage , equal to
SmalltalkImage current.
And SystemDictionary is just a dictionary without any extra utility
methods.
This is option #2 below. (Sorry I didn't recall your post; otherwise I
would've named it the Igor variant :-)
Cheers,
 - Andreas
...
On 2 March 2010 18:32, Chris Muller<asqueaker@gmail.com>  wrote:
...
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab@gmx.de>
 wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten
by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it
now.
The only question is which way. There are two alternatives which achieve
the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary;
implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the
mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
What if instead of writing (SmalltalkImage current) you would just say
(Smalltalk vm).
Would this be tolerably short ?
Would the compatibility layer be short enough ?
Squeak 3.8: SystemDictionary>>vm ^ self
Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current
I took a look, and except source code management, a majority of
SmalltalkImage methods are related to VM and command line.
We could as well move messages to SmalltalkVM and just let a
SmalltalkImage class current hook
But I don't think it is necessary.
What do you think ?
I think we should define a distinctive roles for these parts and make
sure none of them overlap.
'vm' is for tuning/poking GC options/attributes and various
interpreter specific stuff.
'system' is for poking with host system options/attributes
'image' is for poking with language-wide (global) stuff & utils
then , for any behavior it would be clear, what entity is responsible
for it, not like currently
when you don't know what is better 'Smalltalk' or 'SmalltalkImage current'
like this ?
Smalltalk vm version
Smalltalk vm extraMemory
Smalltalk vm listLoadedModules
But then:
Smalltalk vm allocationCount
or Smalltalk memory allocationCount ?
or Smalltalk gc allocationCount ?
Smalltalk host windowSystem
Smalltalk host platformName
Smalltalk host osVersion
Smalltalk commandLine vmPath.
Smalltalk commandLine imagePath.
Smalltalk commandLine documentPath.
Smalltalk commandLine optionNumber: 2.
Smalltalk commandLine options.
Smalltalk commandLine argumentNumber: 1.
Smalltalk commandLine arguments.
Smalltalk sourceCode condenseChanges.
This is very nice.  So...
Smalltalk query allImplementorsOf: #printOn:
Smalltalk query browseSendersOf: #ensure:
?
...
...
--
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: keith <keith_hodges@yahoo.co.uk>
Date: March 2, 2010 10:48:34 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
...
...
Smalltalk host windowSystem
Smalltalk host platformName
Smalltalk host osVersion
Smalltalk commandLine vmPath.
Smalltalk commandLine imagePath.
Smalltalk commandLine documentPath.
Smalltalk commandLine optionNumber: 2.
Smalltalk commandLine optionAt: 2.
Not every protocol has to be implemented by a different class.
I asked earlier about a name for the StartupManager. StartupManager would happily handle #commandLine and probably #host as well.
Keith
Begin forwarded message:
...
From: Andreas Raab <andreas.raab@gmx.de>
Date: March 2, 2010 7:04:45 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
You're precisely repeating all the reasons why I want it fixed :-)
Cheers,
 - Andreas
On 3/1/2010 10:01 PM, Ronald Spengler wrote:
...
Are there things we mean idiomatically by saying Smalltalk which we
don't mean by saying SmalltalkImage?
And why SmalltalkImage current? What does current really mean? Would
you ever say SmalltalkImage lastWeek? Or SmalltalkImage aDate? Or
SmalltalkImage obsolete?
I don't have an opinion, I'm just confused. Isn't the image itself
just Smalltalk?
On Monday, March 1, 2010, Phil (list)<pbpublist@gmail.com>  wrote:
...
On Mar 1, 2010, at 11:08 PM, Andreas Raab wrote:
Folks -
I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
        Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Having dealt with this a few times getting some code running on Cuis, I'd prefer that Squeak/Cuis try to remain compatible in areas like this where there doesn't seem to be any compelling reason for them not to be.  I have no preference whether it's Cuis moving to the Squeak approach or Squeak moving (back) to the Cuis approach though.
Cheers,
 - Andreas
Thanks,
Phil
Begin forwarded message:
...
From: keith <keith_hodges@yahoo.co.uk>
Date: March 2, 2010 12:08:45 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
...
...
...
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Cuis didn't exactly move the code back to SystemDictionary, of course it never left in the first place. It is easier for Cuis to implement compatibility with "trunk" than it is for "trunk" to go back to the old way.
How much code uses Smalltalk at: ? As soon as you put SmalltalkImage current into Smalltalk you have to make what was an "image utilities" class behave like a dictionary.
You seem to be saying, we must have a single place to access this stuff called "Smalltalk". I think what really needs to happen is to factor things up nicely and logically so we know where to find things and can write compatible code.
I propose as a starting point, that we design a scheme or convention that implements the "long hand" variant, and then when happy with this, implement the short hand versions. The most obvious long hand variant.
self class environment "system globals"
self class environment image
self class environment navigation
self class environment sourceFiles
self class environment startupManager.
self class environment organization.
For the shorter hand variants, personally I wouldn't mind these being implemented on Object, aka #systemNavigation.
self systemEnvironment, self systemImage, self systemNavigation, self systemSourceFiles, self systemStartupManager, self systemOrganization
but I think I would prefer an instance side implementation of #environment/#system/#smalltalk
SmalltalkImage current would then become:
self environment image / self smalltalk image.
ok, it's not compatible, but its not a mess either.
The compatibility I would fix temporarily with better code loading tools, or a dnu: on SystemDictionary.
K.
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 12:27:23 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
I like Keith proposition, and  I think it's also urgent to read the
Newspeak ones before making any modification
Nicolas
2010/3/2 keith <keith_hodges@yahoo.co.uk>:
...
1) The Cuis variant: Move all the code back to SystemDictionary; implement
SmalltalkImage current as ^Smalltalk.
Cuis didn't exactly move the code back to SystemDictionary, of course it
never left in the first place. It is easier for Cuis to implement
compatibility with "trunk" than it is for "trunk" to go back to the old way.
How much code uses Smalltalk at: ? As soon as you put SmalltalkImage current
into Smalltalk you have to make what was an "image utilities" class behave
like a dictionary.
You seem to be saying, we must have a single place to access this stuff
called "Smalltalk". I think what really needs to happen is to factor things
up nicely and logically so we know where to find things and can write
compatible code.
I propose as a starting point, that we design a scheme or convention that
implements the "long hand" variant, and then when happy with this, implement
the short hand versions. The most obvious long hand variant.
self class environment "system globals"
self class environment image
self class environment navigation
self class environment sourceFiles
self class environment startupManager.
self class environment organization.
For the shorter hand variants, personally I wouldn't mind these being
implemented on Object, aka #systemNavigation.
self systemEnvironment, self systemImage, self systemNavigation, self
systemSourceFiles, self systemStartupManager, self systemOrganization
but I think I would prefer an instance side implementation of
#environment/#system/#smalltalk
SmalltalkImage current would then become:
self environment image / self smalltalk image.
ok, it's not compatible, but its not a mess either.
The compatibility I would fix temporarily with better code loading tools, or
a dnu: on SystemDictionary.
K.
Begin forwarded message:
...
From: Michael Haupt <mhaupt@gmail.com>
Date: March 2, 2010 12:35:42 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Hi,
On Tue, Mar 2, 2010 at 12:27 PM, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
I like Keith proposition, and  I think it's also urgent to read the
Newspeak ones before making any modification
I also generally like the idea of binding things via messages instead
of via global state, and the Newspeak pointer is just right in this
regard.
But I believe we must not forget that Newspeak is extremely consequent
in that everything is late-bound; Smalltalk just isn't. (Newspeak even
late-binds super classes at object instantiation time.)
Apart from that, Object is already rather cluttered.
Some questions:
How appropriate would such a model be in Smalltalk?
Is there a scenario where "the image" would not be global state? (Hydra?)
Note that I'm not totally opposed to these ideas, just skeptical. :-)
Best,
Michael
Begin forwarded message:
...
From: Igor Stasenko <siguctua@gmail.com>
Date: March 2, 2010 1:18:28 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 2 March 2010 13:35, Michael Haupt <mhaupt@gmail.com> wrote:
...
Hi,
On Tue, Mar 2, 2010 at 12:27 PM, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
I like Keith proposition, and  I think it's also urgent to read the
Newspeak ones before making any modification
I also generally like the idea of binding things via messages instead
of via global state, and the Newspeak pointer is just right in this
regard.
But I believe we must not forget that Newspeak is extremely consequent
in that everything is late-bound; Smalltalk just isn't. (Newspeak even
late-binds super classes at object instantiation time.)
Apart from that, Object is already rather cluttered.
then how about:
thisContext environment "system globals"
thisContext image
thisContext navigation
thisContext sourceFiles
...
?
...
Some questions:
How appropriate would such a model be in Smalltalk?
Is there a scenario where "the image" would not be global state? (Hydra?)
It is. When you building things from scratch, using different object model,
experimenting etc it is important to keep your code and objects
isolated from usual object graph.
...
Note that I'm not totally opposed to these ideas, just skeptical. :-)
Best,
Michael
-- 
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: Michael Haupt <mhaupt@gmail.com>
Date: March 2, 2010 2:37:19 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Hi Igor,
On Tue, Mar 2, 2010 at 1:18 PM, Igor Stasenko <siguctua@gmail.com> wrote:
...
...
Apart from that, Object is already rather cluttered.
then how about:
thisContext environment "system globals" ...
eh, in my opinion, that's even more awkward. Why should these things
be associated with a Context? Of all *classes*, Object would be the
appropriate place for such things, but see above. :-)
...
...
Some questions:
How appropriate would such a model be in Smalltalk?
Is there a scenario where "the image" would not be global state? (Hydra?)
It is. When you building things from scratch, using different object model,
experimenting etc it is important to keep your code and objects
isolated from usual object graph.
Yes, I figured this would make sense.
Best,
Michael
Begin forwarded message:
...
From: Eliot Miranda <eliot.miranda@gmail.com>
Date: March 2, 2010 6:04:00 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges@yahoo.co.uk> wrote:
...
...
...
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Cuis didn't exactly move the code back to SystemDictionary, of course it never left in the first place. It is easier for Cuis to implement compatibility with "trunk" than it is for "trunk" to go back to the old way.
How much code uses Smalltalk at: ? As soon as you put SmalltalkImage current into Smalltalk you have to make what was an "image utilities" class behave like a dictionary.
You seem to be saying, we must have a single place to access this stuff called "Smalltalk". I think what really needs to happen is to factor things up nicely and logically so we know where to find things and can write compatible code.
I propose as a starting point, that we design a scheme or convention that implements the "long hand" variant, and then when happy with this, implement the short hand versions. The most obvious long hand variant.
self class environment "system globals"
self class environment image
self class environment navigation
self class environment sourceFiles
self class environment startupManager.
self class environment organization.
This doesn't make sense in a workspace where the notion of the current class is a weak one (current class is UndefinedObject for want of having no class at all).
Why are global names worse than any of these?
I think Smalltalk == System is a good approach.  Making things verbose is a very poor direction.  When a cluster of associated behaviours gets complex enough then by all means move it out to a class.  So in VisualWorks the pairing of ObjectMemory and MemoryPolicy which allows inspection and tailoring of memory management makes sense.
A Tools object for systemNavigation might make sense, but SystemNavigation is a poor name; long (SystemNavigation default being worse) and not very informative.  BrowserQuery would be better.  Browse would be better.
The worst thing going on with things like SmalltalkImage current, SystemNavigation default and traits is the introduction of abstraction for its own sake.  Abstraction is properly used to manage complexity.  But for example, as others have pointed out, there is no other image than the current image and so SmalltalkImage current is merely verbiage.  And yet SourceFiles is an obvious area which could use a lot more features (being able to load package sources without appending them to the sources file, or having two changes files, one for loaded packages, one for user modifications, etc).
Another bad thing is not thinking about names.  Names are extremely important for making sense of a system, most especially for new users.  Finding a vivid short name is well worth extra effort.
I'd love to see someone start a side project which comprised
- a minimal kernel image, capable of bootstrapping (so includes base class library, compiler, gui-less debugger/back-tracer, file system interface)
- a set of packages comprising loadable programming tools
- a refactoring engine and rules base for converting from the current Squeak dialects where the rules were renamings of things like "SystemNavigation default" into "Browse"
and which focussed on a new set of global names for the environment.  The base class library would stay the same, but Smalltalk, SystemNavigation, SmalltalkImage etc would be up for grabs.
I'd then love to see a university department divide a class into two and see how each set of students faired with each variant, each provided with otherwise identical introductory material that differed only in the names & organization of these system services classes.
For the shorter hand variants, personally I wouldn't mind these being implemented on Object, aka #systemNavigation.
self systemEnvironment, self systemImage, self systemNavigation, self systemSourceFiles, self systemStartupManager, self systemOrganization
but I think I would prefer an instance side implementation of #environment/#system/#smalltalk
SmalltalkImage current would then become:
self environment image / self smalltalk image.
ok, it's not compatible, but its not a mess either.
The compatibility I would fix temporarily with better code loading tools, or a dnu: on SystemDictionary.
K.
Begin forwarded message:
...
From: Andreas Raab <andreas.raab@gmx.de>
Date: March 2, 2010 8:53:32 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 3/2/2010 8:55 AM, Igor Stasenko wrote:
...
If you remember previous discussion about this, i proposed to use
Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
so, that Smalltalk>>at: x
implemented as
  globals at: x
then Smalltalk global is an instance of SmalltalkImage , equal to
SmalltalkImage current.
And SystemDictionary is just a dictionary without any extra utility methods.
This is option #2 below. (Sorry I didn't recall your post; otherwise I would've named it the Igor variant :-)
Cheers,
 - Andreas
...
On 2 March 2010 18:32, Chris Muller<asqueaker@gmail.com>  wrote:
...
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab@gmx.de>  wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now.
The only question is which way. There are two alternatives which achieve the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 9:00:43 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/2 Andreas Raab <andreas.raab@gmx.de>:
...
On 3/2/2010 8:55 AM, Igor Stasenko wrote:
...
If you remember previous discussion about this, i proposed to use
Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
so, that Smalltalk>>at: x
implemented as
  globals at: x
then Smalltalk global is an instance of SmalltalkImage , equal to
SmalltalkImage current.
And SystemDictionary is just a dictionary without any extra utility
methods.
This is option #2 below. (Sorry I didn't recall your post; otherwise I
would've named it the Igor variant :-)
Cheers,
 - Andreas
...
On 2 March 2010 18:32, Chris Muller<asqueaker@gmail.com>  wrote:
...
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab@gmx.de>
 wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten
by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it
now.
The only question is which way. There are two alternatives which achieve
the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary;
implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the
mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
What if instead of writing (SmalltalkImage current) you would just say
(Smalltalk vm).
Would this be tolerably short ?
Would the compatibility layer be short enough ?
Squeak 3.8: SystemDictionary>>vm ^ self
Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current
I took a look, and except source code management, a majority of
SmalltalkImage methods are related to VM and command line.
We could as well move messages to SmalltalkVM and just let a
SmalltalkImage class current hook
But I don't think it is necessary.
What do you think ?
Begin forwarded message:
...
From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Date: March 2, 2010 9:03:51 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
2010/3/2 Eliot Miranda <eliot.miranda@gmail.com>:
...
On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges@yahoo.co.uk> wrote:
...
1) The Cuis variant: Move all the code back to SystemDictionary; implement
SmalltalkImage current as ^Smalltalk.
Cuis didn't exactly move the code back to SystemDictionary, of course it
never left in the first place. It is easier for Cuis to implement
compatibility with "trunk" than it is for "trunk" to go back to the old way.
How much code uses Smalltalk at: ? As soon as you put SmalltalkImage
current into Smalltalk you have to make what was an "image utilities" class
behave like a dictionary.
You seem to be saying, we must have a single place to access this stuff
called "Smalltalk". I think what really needs to happen is to factor things
up nicely and logically so we know where to find things and can write
compatible code.
I propose as a starting point, that we design a scheme or convention that
implements the "long hand" variant, and then when happy with this, implement
the short hand versions. The most obvious long hand variant.
self class environment "system globals"
self class environment image
self class environment navigation
self class environment sourceFiles
self class environment startupManager.
self class environment organization.
This doesn't make sense in a workspace where the notion of the current class
is a weak one (current class is UndefinedObject for want of having no class
at all).
Why are global names worse than any of these?
I think Smalltalk == System is a good approach.  Making things verbose is a
very poor direction.  When a cluster of associated behaviours gets complex
enough then by all means move it out to a class.  So in VisualWorks the
pairing of ObjectMemory and MemoryPolicy which allows inspection and
tailoring of memory management makes sense.
A Tools object for systemNavigation might make sense, but SystemNavigation
is a poor name; long (SystemNavigation default being worse) and not very
informative.  BrowserQuery would be better.  Browse would be better.
Maybe a SystemNavigation was introduced to handle the fact that there
were many different browsers... Or Morphic + MVC....
Maybe some were thinking embedding a default + some alternatives in a
single image...
(Browser browseAllCallsOn: #yourself) was just perfectly short :)
Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we
really want to avoid pairing each message.
A pity that Browser itself failed to become the abstract factory which
SystemNavigation default is...
...
The worst thing going on with things like SmalltalkImage current,
SystemNavigation default and traits is the introduction of abstraction for
its own sake.  Abstraction is properly used to manage complexity.  But for
example, as others have pointed out, there is no other image than the
current image and so SmalltalkImage current is merely verbiage.  And yet
SourceFiles is an obvious area which could use a lot more features (being
able to load package sources without appending them to the sources file, or
having two changes files, one for loaded packages, one for user
modifications, etc).
Another bad thing is not thinking about names.  Names are extremely
important for making sense of a system, most especially for new users.
 Finding a vivid short name is well worth extra effort.
I'd love to see someone start a side project which comprised
- a minimal kernel image, capable of bootstrapping (so includes base class
library, compiler, gui-less debugger/back-tracer, file system interface)
- a set of packages comprising loadable programming tools
- a refactoring engine and rules base for converting from the current Squeak
dialects where the rules were renamings of things like "SystemNavigation
default" into "Browse"
and which focussed on a new set of global names for the environment.  The
base class library would stay the same, but Smalltalk, SystemNavigation,
SmalltalkImage etc would be up for grabs.
I'd then love to see a university department divide a class into two and see
how each set of students faired with each variant, each provided with
otherwise identical introductory material that differed only in the names &
organization of these system services classes.
...
For the shorter hand variants, personally I wouldn't mind these being
implemented on Object, aka #systemNavigation.
self systemEnvironment, self systemImage, self systemNavigation, self
systemSourceFiles, self systemStartupManager, self systemOrganization
but I think I would prefer an instance side implementation of
#environment/#system/#smalltalk
SmalltalkImage current would then become:
self environment image / self smalltalk image.
ok, it's not compatible, but its not a mess either.
The compatibility I would fix temporarily with better code loading tools,
or a dnu: on SystemDictionary.
K.
Begin forwarded message:
...
From: Igor Stasenko <siguctua@gmail.com>
Date: March 2, 2010 9:07:10 PM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 2 March 2010 22:00, Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com> wrote:
...
2010/3/2 Andreas Raab <andreas.raab@gmx.de>:
...
On 3/2/2010 8:55 AM, Igor Stasenko wrote:
...
If you remember previous discussion about this, i proposed to use
Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
so, that Smalltalk>>at: x
implemented as
  globals at: x
then Smalltalk global is an instance of SmalltalkImage , equal to
SmalltalkImage current.
And SystemDictionary is just a dictionary without any extra utility
methods.
This is option #2 below. (Sorry I didn't recall your post; otherwise I
would've named it the Igor variant :-)
Cheers,
 - Andreas
...
On 2 March 2010 18:32, Chris Muller<asqueaker@gmail.com>  wrote:
...
Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
Smalltalk's main responsibility is mapping the list of global names to
their global objects, and providing access to them by direct
reference.
I don't understand why would want to commingle a bunch of utility
methods in with this primary (global name mapping) responsibility..?
What is the problem exactly?
Also, I'm curious about Cuis compatibility; is this really realistic
or important?  Why is it important?  This would seem to be a
relatively superficial difference with Cuis and other Smalltalk's, so
I hope we will base decisions on what we think is the "right thing" to
do rather than compatibility with something else that might not
matter..
On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab@gmx.de>
 wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten
by
this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it
now.
The only question is which way. There are two alternatives which achieve
the
goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary;
implement
SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to
SmalltalkImage; add a 'globals' variable (populated by an instance of
SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the
mess
we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
 - Andreas
What if instead of writing (SmalltalkImage current) you would just say
(Smalltalk vm).
Would this be tolerably short ?
Would the compatibility layer be short enough ?
Squeak 3.8: SystemDictionary>>vm ^ self
Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current
I took a look, and except source code management, a majority of
SmalltalkImage methods are related to VM and command line.
We could as well move messages to SmalltalkVM and just let a
SmalltalkImage class current hook
But I don't think it is necessary.
What do you think ?
I think we should define a distinctive roles for these parts and make
sure none of them overlap.
'vm' is for tuning/poking GC options/attributes and various
interpreter specific stuff.
'system' is for poking with host system options/attributes
'image' is for poking with language-wide (global) stuff & utils
then , for any behavior it would be clear, what entity is responsible
for it, not like currently
when you don't know what is better 'Smalltalk' or 'SmalltalkImage current'
-- 
Best regards,
Igor Stasenko AKA sig.
Begin forwarded message:
...
From: Ronald Spengler <ron.spengler@gmail.com>
Date: March 2, 2010 7:01:47 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Are there things we mean idiomatically by saying Smalltalk which we
don't mean by saying SmalltalkImage?
And why SmalltalkImage current? What does current really mean? Would
you ever say SmalltalkImage lastWeek? Or SmalltalkImage aDate? Or
SmalltalkImage obsolete?
I don't have an opinion, I'm just confused. Isn't the image itself
just Smalltalk?
On Monday, March 1, 2010, Phil (list) <pbpublist@gmail.com> wrote:
...
On Mar 1, 2010, at 11:08 PM, Andreas Raab wrote:
Folks -
I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
       Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Having dealt with this a few times getting some code running on Cuis, I'd prefer that Squeak/Cuis try to remain compatible in areas like this where there doesn't seem to be any compelling reason for them not to be.  I have no preference whether it's Cuis moving to the Squeak approach or Squeak moving (back) to the Cuis approach though.
Cheers,
 - Andreas
Thanks,
Phil
-- 
Ron
Begin forwarded message:
...
From: Bert Freudenberg <bert@freudenbergs.de>
Date: March 2, 2010 8:21:53 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On 02.03.2010, at 05:08, Andreas Raab wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
  Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Cheers,
- Andreas
1) +1
2) -0
- Bert -
Begin forwarded message:
...
From: "Phil (list)" <pbpublist@gmail.com>
Date: March 2, 2010 6:38:58 AM GMT+01:00
To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
On Mar 1, 2010, at 11:08 PM, Andreas Raab wrote:
...
Folks -
I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk":
1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk.
Pro: Compatible with Cuis.
Con: Lack of separation of concerns.
2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this:
SmalltalkImage current globals: Smalltalk.
  Smalltalk := SmalltalkImage current.
Pro: Better separation of concerns.
Con: Different from Cuis.
I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current".
If you have an opinion, voice it, otherwise I'll just pick one.
Having dealt with this a few times getting some code running on Cuis, I'd prefer that Squeak/Cuis try to remain compatible in areas like this where there doesn't seem to be any compelling reason for them not to be.  I have no preference whether it's Cuis moving to the Squeak approach or Squeak moving (back) to the Cuis approach though.
...
Cheers,
- Andreas
Thanks,
Phil

[Pharo-project] Worth reading discussion on Smalltalk vs SmalltalkImage

StÃ©phane Ducasse