SmalltalkImage current vs. Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

SmalltalkImage current vs. Smalltalk

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Phil B
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

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Casey Ransberger
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

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Andreas.Raab
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
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Bert Freudenberg
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 -



Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

keith1y
In reply to this post by Andreas.Raab
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.








Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Nicolas Cellier
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.
>
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Michael Haupt-3
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

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Stéphane Rollandin
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



Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Michael Haupt-3
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

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Nicolas Cellier
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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Chris Muller-3
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Eliot Miranda-2
In reply to this post by keith1y


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.












Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Andreas.Raab
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
>>>
>>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: SmalltalkImage current vs. Smalltalk

Nicolas Cellier
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 ?

123