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 |
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 |
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 |
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 >> >> > |
In reply to this post by Andreas.Raab
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 - |
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 |
In reply to this post by Andreas.Raab
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. |
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. > > > > > > > > > |
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 |
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. > 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. |
In reply to this post by Nicolas Cellier
> 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 |
In reply to this post by Igor Stasenko
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 |
In reply to this post by Stéphane Rollandin
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 > > > > |
In reply to this post by Andreas.Raab
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 |
In reply to this post by Nicolas Cellier
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 |
In reply to this post by Andreas.Raab
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 > > |
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. |
In reply to this post by keith1y
On Tue, Mar 2, 2010 at 3:08 AM, keith <[hidden email]> wrote:
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.
|
In reply to this post by Igor Stasenko
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 >>> >>> >> >> > > > |
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 ? |
Free forum by Nabble | Edit this page |