On Tue, Mar 2, 2010 at 1:20 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 2010/3/2 Igor Stasenko <siguctua at gmail.com>:
> > On 2 March 2010 22:00, Nicolas Cellier
> > <nicolas.cellier.aka.nice at gmail.com> wrote:
> >> 2010/3/2 Andreas Raab <andreas.raab at gmx.de>:
> >>> On 3/2/2010 8:55 AM, Igor Stasenko wrote:
> >>>>
> >>>> If you remember previous discussion about this, i proposed to use
> >>>> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
> >>>> so, that Smalltalk>>at: x
> >>>> implemented as
> >>>>   globals at: x
> >>>>
> >>>> then Smalltalk global is an instance of SmalltalkImage , equal to
> >>>> SmalltalkImage current.
> >>>> And SystemDictionary is just a dictionary without any extra utility
> >>>> methods.
> >>>
> >>> This is option #2 below. (Sorry I didn't recall your post; otherwise I
> >>> would've named it the Igor variant :-)
> >>>
> >>> Cheers,
> >>>  - Andreas
> >>>
> >>>> On 2 March 2010 18:32, Chris Muller<asqueaker at gmail.com>  wrote:
> >>>>>
> >>>>> Smalltalk is a SystemDictionary, which is-a Dictionary.  This
> suggests
> >>>>> Smalltalk's main responsibility is mapping the list of global names
> to
> >>>>> their global objects, and providing access to them by direct
> >>>>> reference.
> >>>>>
> >>>>> I don't understand why would want to commingle a bunch of utility
> >>>>> methods in with this primary (global name mapping) responsibility..?
> >>>>>
> >>>>> What is the problem exactly?
> >>>>>
> >>>>> Also, I'm curious about Cuis compatibility; is this really realistic
> >>>>> or important?  Why is it important?  This would seem to be a
> >>>>> relatively superficial difference with Cuis and other Smalltalk's, so
> >>>>> I hope we will base decisions on what we think is the "right thing"
> to
> >>>>> do rather than compatibility with something else that might not
> >>>>> matter..
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab at gmx.de>
> >>>>>  wrote:
> >>>>>>
> >>>>>> Folks -
> >>>>>>
> >>>>>> I was just trying to load some other code and once too many I got
> bitten
> >>>>>> by
> >>>>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix
> it
> >>>>>> now.
> >>>>>> The only question is which way. There are two alternatives which
> achieve
> >>>>>> the
> >>>>>> goal of "SmalltalkImage current == Smalltalk":
> >>>>>>
> >>>>>> 1) The Cuis variant: Move all the code back to SystemDictionary;
> >>>>>> implement
> >>>>>> SmalltalkImage current as ^Smalltalk.
> >>>>>>
> >>>>>> Pro: Compatible with Cuis.
> >>>>>> Con: Lack of separation of concerns.
> >>>>>>
> >>>>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary
> to
> >>>>>> SmalltalkImage; add a 'globals' variable (populated by an instance
> of
> >>>>>> SystemDictionary) and convert everything roughly like this:
> >>>>>>
> >>>>>>        SmalltalkImage current globals: Smalltalk.
> >>>>>>        Smalltalk := SmalltalkImage current.
> >>>>>>
> >>>>>> Pro: Better separation of concerns.
> >>>>>> Con: Different from Cuis.
> >>>>>>
> >>>>>> I really don't care which way we do it; all I want is to get out of
> the
> >>>>>> mess
> >>>>>> we've created by introducing "SmalltalkImage current".
> >>>>>>
> >>>>>> If you have an opinion, voice it, otherwise I'll just pick one.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>  - Andreas
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >> What if instead of writing (SmalltalkImage current) you would just say
> >> (Smalltalk vm).
> >> Would this be tolerably short ?
> >> Would the compatibility layer be short enough ?
> >>
> >> Squeak 3.8: SystemDictionary>>vm ^ self
> >> Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current
> >>
> >> I took a look, and except source code management, a majority of
> >> SmalltalkImage methods are related to VM and command line.
> >> We could as well move messages to SmalltalkVM and just let a
> >> SmalltalkImage class current hook
> >> But I don't think it is necessary.
> >>
> >> What do you think ?
> >>
> >>
> > I think we should define a distinctive roles for these parts and make
> > sure none of them overlap.
> > 'vm' is for tuning/poking GC options/attributes and various
> > interpreter specific stuff.
> > 'system' is for poking with host system options/attributes
> > 'image' is for poking with language-wide (global) stuff & utils
> >
> > then , for any behavior it would be clear, what entity is responsible
> > for it, not like currently
> > when you don't know what is better 'Smalltalk' or 'SmalltalkImage
> current'
> >
>
> like this ?
>
> Smalltalk vm version
> Smalltalk vm extraMemory
> Smalltalk vm listLoadedModules
>
> But then:
> Smalltalk vm allocationCount
> or Smalltalk memory allocationCount ?
> or Smalltalk gc allocationCount ?
>
> Smalltalk host windowSystem
> Smalltalk host platformName
> Smalltalk host osVersion
>
> Smalltalk commandLine vmPath.
> Smalltalk commandLine imagePath.
> Smalltalk commandLine documentPath.
> Smalltalk commandLine optionNumber: 2.
> Smalltalk commandLine options.
> Smalltalk commandLine argumentNumber: 1.
> Smalltalk commandLine arguments.
>
> Smalltalk sourceCode condenseChanges.
>

This is very nice.  So...

Smalltalk query allImplementorsOf: #printOn:
Smalltalk query browseSendersOf: #ensure:

?

...
>
>
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100302/53884cb6/attachment.htm