SmalltalkImage current vs. Smalltalk
Locked
123
123
Re: SmalltalkImage current vs. Smalltalk
 
|
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. >> >> >> >> >> >> >> >> > > > > > |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Nicolas Cellier
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 ? > > 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. |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Nicolas Cellier
On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier <[hidden email]> wrote: 2010/3/2 Eliot Miranda <[hidden email]>: 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.
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)?
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.
|
Re: SmalltalkImage current vs. Smalltalk
|
|
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. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> > >> > >> > >> > > > > > |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Igor Stasenko
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. > > |
Re: SmalltalkImage current vs. Smalltalk
|
|
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 ? > > 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. |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Nicolas Cellier
On Tue, Mar 2, 2010 at 1:20 PM, Nicolas Cellier <[hidden email]> wrote: 2010/3/2 Igor Stasenko <[hidden email]>: This is very nice. So... Smalltalk query allImplementorsOf: #printOn: Smalltalk query browseSendersOf: #ensure:
? ... |
|
|
In reply to this post by Igor Stasenko
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 |
Re: SmalltalkImage current vs. Smalltalk
|
|
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 > > |
Re: SmalltalkImage current vs. Smalltalk
|
|
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. |
Re: SmalltalkImage current vs. Smalltalk
|
|
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. |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Andreas.Raab
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 > > |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Eliot Miranda-2
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 |
|
|
On 3 Mar 2010, at 02:45, Andreas Raab wrote:
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 |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Andreas.Raab
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 |
|
In reply to this post by Andreas.Raab
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 > > |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Casey Ransberger
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 >> >> > |
Re: SmalltalkImage current vs. Smalltalk
|
|
In reply to this post by Andreas.Raab
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 |
Re: SmalltalkImage current vs. Smalltalk
|
|
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 |
Re: SmalltalkImage current vs. Smalltalk
|
|
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |