Worth reading discussion on Smalltalk vs SmalltalkImage

> From: Andreas Raab <[hidden email]>
> Date: March 2, 2010 5:08:56 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 10:56:03 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 2010/3/2 keith <[hidden email]>:
>>
>> 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
>
>>
>>
>

> From: Igor Stasenko <[hidden email]>
> Date: March 2, 2010 11:00:26 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> So, looks like we having a good consensus?
> /me always happy when it happens :)
>
> On 2 March 2010 23:56, Nicolas Cellier
> <[hidden email]> wrote:
>> 2010/3/2 keith <[hidden email]>:
>>>
>>> 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.
>

> From: Igor Stasenko <[hidden email]>
> Date: March 2, 2010 11:10:29 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> Haha..
> i just recalled that i proposed something like this before.
> Here it is:
> http://www.mail-archive.com/pharo-project@.../msg02869.html
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> From: Andreas Raab <[hidden email]>
> Date: March 3, 2010 3:41:22 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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
>>
>>
>
>

> From: Andreas Raab <[hidden email]>
> Date: March 3, 2010 3:45:10 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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
>

> From: keith <[hidden email]>
> Date: March 3, 2010 4:15:51 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
>
> 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
>

> From: Andreas Raab <[hidden email]>
> Date: March 3, 2010 5:01:05 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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<[hidden email]>  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
>>>
>>>
>>
>
>

> From: Michael Haupt <[hidden email]>
> Date: March 3, 2010 7:14:27 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> Hi,
>
> Am 03.03.2010 um 03:41 schrieb Andreas Raab <[hidden email]>:
>> Consequently I'm going to completely ignore any forward-looking proposals and simply state that the current count is 3 votes for the first variant (Phil, David, Bert) and 1 vote for the second variant (Igor).
>
> here's another for "Smalltalk", then.
>
> Best,
>
> Michael
>

> From: Andreas Raab <[hidden email]>
> Date: March 3, 2010 7:38:12 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> On 3/2/2010 10:14 PM, Michael Haupt wrote:
>> Hi,
>>
>> Am 03.03.2010 um 03:41 schrieb Andreas Raab <[hidden email]>:
>>> Consequently I'm going to completely ignore any forward-looking
>>> proposals and simply state that the current count is 3 votes for the
>>> first variant (Phil, David, Bert) and 1 vote for the second variant
>>> (Igor).
>>
>> here's another for "Smalltalk", then.
>
> That choice doesn't exist :-) You can vote for:
>
> a) Smalltalk class == SystemDictionary, or
>
> b) Smalltalk class == SmalltalkImage
>
> Cheers,
>  - Andreas
>

> From: Michael Haupt <[hidden email]>
> Date: March 3, 2010 8:57:02 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> Hi again,
>
> On Wed, Mar 3, 2010 at 7:38 AM, Andreas Raab <[hidden email]> 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
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 10:05:13 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 2010/3/2 Bert Freudenberg <[hidden email]>:
>> 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
>

> From: Stéphane Rollandin <[hidden email]>
> Date: March 2, 2010 1:18:55 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
>> 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
>
>
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 4:41:52 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 2010/3/2 Stéphane Rollandin <[hidden email]>:
>>> 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
>>
>>
>>
>>
>

> From: "David T. Lewis" <[hidden email]>
> Date: March 2, 2010 5:24:18 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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
>
>

> From: "David T. Lewis" <[hidden email]>
> Date: March 2, 2010 5:27:24 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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
>
>

> From: Chris Muller <[hidden email]>
> Date: March 2, 2010 5:32:34 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: [hidden email], The general-purpose Squeak developers list <[hidden email]>
>
> 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 <[hidden email]> 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
>>
>>
>

> From: Igor Stasenko <[hidden email]>
> Date: March 2, 2010 5:55:10 PM GMT+01:00
> To: [hidden email], The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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 <[hidden email]> 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 <[hidden email]> 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.
>

> From: Ronald Spengler <[hidden email]>
> Date: March 3, 2010 4:21:26 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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 <[hidden email]> 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
>

> From: Alexander Lazarević <[hidden email]>
> Date: March 3, 2010 4:26:22 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 1) +1
>
> On Tue, Mar 2, 2010 at 05:08, Andreas Raab <[hidden email]> 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
>>
>>
>

> From: Eliot Miranda <[hidden email]>
> Date: March 2, 2010 9:41:35 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
>
>
> On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier <[hidden email]> wrote:
> 2010/3/2 Eliot Miranda <[hidden email]>:
> >
> >
> > On Tue, Mar 2, 2010 at 3:08 AM, keith <[hidden email]> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 10:07:33 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 2010/3/2 Eliot Miranda <[hidden email]>:
>>
>>
>> On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier
>> <[hidden email]> wrote:
>>>
>>> 2010/3/2 Eliot Miranda <[hidden email]>:
>>>>
>>>>
>>>> On Tue, Mar 2, 2010 at 3:08 AM, keith <[hidden email]> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 10:20:34 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 2010/3/2 Igor Stasenko <[hidden email]>:
>> On 2 March 2010 22:00, Nicolas Cellier
>> <[hidden email]> wrote:
>>> 2010/3/2 Andreas Raab <[hidden email]>:
>>>> 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<[hidden email]>  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<[hidden email]>
>>>>>>  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.
>>
>>
>

> From: Igor Stasenko <[hidden email]>
> Date: March 2, 2010 10:35:22 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> On 2 March 2010 23:20, Nicolas Cellier
> <[hidden email]> wrote:
>> 2010/3/2 Igor Stasenko <[hidden email]>:
>>> On 2 March 2010 22:00, Nicolas Cellier
>>> <[hidden email]> wrote:
>>>> 2010/3/2 Andreas Raab <[hidden email]>:
>>>>> 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<[hidden email]>  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<[hidden email]>
>>>>>>>  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.
>

> From: Eliot Miranda <[hidden email]>
> Date: March 2, 2010 10:44:16 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
>
>
> On Tue, Mar 2, 2010 at 1:20 PM, Nicolas Cellier <[hidden email]> wrote:
> 2010/3/2 Igor Stasenko <[hidden email]>:
> > On 2 March 2010 22:00, Nicolas Cellier
> > <[hidden email]> wrote:
> >> 2010/3/2 Andreas Raab <[hidden email]>:
> >>> 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<[hidden email]>  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<[hidden email]>
> >>>>>  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.
> >
> >
>
>
>

> From: keith <[hidden email]>
> Date: March 2, 2010 10:48:34 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
>>
>>> 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
>  
>

> From: Andreas Raab <[hidden email]>
> Date: March 2, 2010 7:04:45 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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)<[hidden email]>  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
>>>
>>>
>>
>
>

> From: keith <[hidden email]>
> Date: March 2, 2010 12:08:45 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
>>>> 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.
>
>
>
>
>
>
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 12:27:23 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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 <[hidden email]>:
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

> From: Michael Haupt <[hidden email]>
> Date: March 2, 2010 12:35:42 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> Hi,
>
> On Tue, Mar 2, 2010 at 12:27 PM, Nicolas Cellier
> <[hidden email]> 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
>

> From: Igor Stasenko <[hidden email]>
> Date: March 2, 2010 1:18:28 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> On 2 March 2010 13:35, Michael Haupt <[hidden email]> wrote:
>> Hi,
>>
>> On Tue, Mar 2, 2010 at 12:27 PM, Nicolas Cellier
>> <[hidden email]> 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.
>

> From: Michael Haupt <[hidden email]>
> Date: March 2, 2010 2:37:19 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> Hi Igor,
>
> On Tue, Mar 2, 2010 at 1:18 PM, Igor Stasenko <[hidden email]> 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
>

> From: Eliot Miranda <[hidden email]>
> Date: March 2, 2010 6:04:00 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
>
>
> On Tue, Mar 2, 2010 at 3:08 AM, keith <[hidden email]> 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.
>
>
>
>
>
>
>
>
>
>
>

> From: Andreas Raab <[hidden email]>
> Date: March 2, 2010 8:53:32 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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<[hidden email]>  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<[hidden email]>  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
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 9:00:43 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 2010/3/2 Andreas Raab <[hidden email]>:
>> 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<[hidden email]>  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<[hidden email]>
>>>>  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 ?
>

> From: Nicolas Cellier <[hidden email]>
> Date: March 2, 2010 9:03:51 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 2010/3/2 Eliot Miranda <[hidden email]>:
>>
>>
>> On Tue, Mar 2, 2010 at 3:08 AM, keith <[hidden email]> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>

> From: Igor Stasenko <[hidden email]>
> Date: March 2, 2010 9:07:10 PM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> On 2 March 2010 22:00, Nicolas Cellier
> <[hidden email]> wrote:
>> 2010/3/2 Andreas Raab <[hidden email]>:
>>> 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<[hidden email]>  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<[hidden email]>
>>>>>  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.
>

> From: Ronald Spengler <[hidden email]>
> Date: March 2, 2010 7:01:47 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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) <[hidden email]> 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
>

> From: Bert Freudenberg <[hidden email]>
> Date: March 2, 2010 8:21:53 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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 -
>
>
>

> From: "Phil (list)" <[hidden email]>
> Date: March 2, 2010 6:38:58 AM GMT+01:00
> To: The general-purpose Squeak developers list <[hidden email]>
> Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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
>

>
>
> Den 03.03.2010 10:36, skrev Stéphane Ducasse:
>> 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
>>
> I have to say I support what to me seemed like the general consensus on
> this, that the separation just didn't go far enough to make it worth it :)
> I especially like the
> Smalltalk vm parameterAt:
> Smalltalk query allCallsOn:
> etc.
> protocol, sure you add a globals category to SystemDictionary, but to me
> the resulting code looks much better than both the current state of
> SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn:
> (or were those class methods?), and the old where SystemDictionary was a
> complete mess.

>
> On Mar 3, 2010, at 1:28 PM, Henrik Johansen wrote:
>
>>
>>
>> Den 03.03.2010 10:36, skrev Stéphane Ducasse:
>>> 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
>>>
>> I have to say I support what to me seemed like the general consensus on
>> this, that the separation just didn't go far enough to make it worth it :)
>> I especially like the
>> Smalltalk vm parameterAt:
>> Smalltalk query allCallsOn:
>> etc.
>> protocol, sure you add a globals category to SystemDictionary, but to me
>> the resulting code looks much better than both the current state of
>> SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn:
>> (or were those class methods?), and the old where SystemDictionary was a
>> complete mess.
>
> I agree with part of it (see my next/previous mail :)
>
> even if for SystemNavigation I do not really like Smalltalk query ccalll....
>

>> The important thing if this becomes the solution, is deciding what goes
>> where, (in a consistent fashion across forks),
>
> I'm sure that we will be able to have something that is cross fork. I do not have the energy
> to argue.
>
>> as well as the level of
>> backwards-compatibility packages should be offered/deprecation methods
>> kept in the image.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2010/3/3 Stéphane Ducasse <[hidden email]>:
>>
>> On Mar 3, 2010, at 1:28 PM, Henrik Johansen wrote:
>>
>>>
>>>
>>> Den 03.03.2010 10:36, skrev Stéphane Ducasse:
>>>> 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
>>>>
>>> I have to say I support what to me seemed like the general consensus on
>>> this, that the separation just didn't go far enough to make it worth it :)
>>> I especially like the
>>> Smalltalk vm parameterAt:
>>> Smalltalk query allCallsOn:
>>> etc.
>>> protocol, sure you add a globals category to SystemDictionary, but to me
>>> the resulting code looks much better than both the current state of
>>> SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn:
>>> (or were those class methods?), and the old where SystemDictionary was a
>>> complete mess.
>>
>> I agree with part of it (see my next/previous mail :)
>>
>> even if for SystemNavigation I do not really like Smalltalk query ccalll....
>>
>
> My own position is this one:
>
> 1) Rename Browser -> SystemBrowser
> 2) Rename SystemNavigation -> Browser
> 3) move SystemNavigation methods -> class side
>
> Rationale:
> 1) that's what is written in window title, isn't it ?
> 2) Browser allCallsOn: and Browser browseAllCallsOn: are so neat !
> 3) Is there any value in instance side, or is SystemNavigation just a factory ?
>
> Browser would not designate the tool, but the friendly compagnon used
> to browse and query.
> You can easily create a few compatibility hooks to SystemBrowser if required.
>
> Nicolas
>

>>> The important thing if this becomes the solution, is deciding what goes
>>> where, (in a consistent fashion across forks),
>>
>> I'm sure that we will be able to have something that is cross fork. I do not have the energy
>> to argue.
>>
>>> as well as the level of
>>> backwards-compatibility packages should be offered/deprecation methods
>>> kept in the image.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

>
> Rationale:
> 1) that's what is written in window title, isn't it ?
> 2) Browser allCallsOn: and Browser browseAllCallsOn: are so neat !
> 3) Is there any value in instance side, or is SystemNavigation just a factory ?
>
> Browser would not designate the tool, but the friendly compagnon used
> to browse and query.
> You can easily create a few compatibility hooks to SystemBrowser if required.
>
> Nicolas
>
>>> The important thing if this becomes the solution, is deciding what goes
>>> where, (in a consistent fashion across forks),
>>
>> I'm sure that we will be able to have something that is cross fork. I do not have the energy
>> to argue.
>>
>>> as well as the level of
>>> backwards-compatibility packages should be offered/deprecation methods
>>> kept in the image.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> 1) Rename Browser -> SystemBrowser
>> 2) Rename SystemNavigation -> Browser
>> 3) move SystemNavigation methods -> class side
>
> Why not
>        Navigator
>        Finder and we do not change all the existing books that always called Browser the tool
>
>        Finder allCallOn: #new
> Stef

>>
>> Rationale:
>> 1) that's what is written in window title, isn't it ?
>> 2) Browser allCallsOn: and Browser browseAllCallsOn: are so neat !
>> 3) Is there any value in instance side, or is SystemNavigation just a factory ?
>>
>> Browser would not designate the tool, but the friendly compagnon used
>> to browse and query.
>> You can easily create a few compatibility hooks to SystemBrowser if required.
>>
>> Nicolas
>>
>>>> The important thing if this becomes the solution, is deciding what goes
>>>> where, (in a consistent fashion across forks),
>>>
>>> I'm sure that we will be able to have something that is cross fork. I do not have the energy
>>> to argue.
>>>
>>>> as well as the level of
>>>> backwards-compatibility packages should be offered/deprecation methods
>>>> kept in the image.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>