SmalltalkImage current vs Smalltalk : plan B

For now, plan A has more votes than plan B.
plan A: move all SmalltalkImage methods back into SystemDictionary in trunk.
            Let SmalltalkImage current ^Smalltalk for crossfork compatibility
plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class =
SystemDictionary.
           Use messages indirections like:
           Smalltalk vm imagePath
           Smalltalk commandLine optionAt: 2.
           etc... (see previous thread)

At 1st step, they are not much different:
both unify Smalltalk and SmalltalkImage current API.

Also Plan A is much simpler, thus attractive. But:
- Plan A is essentially coming back to 3.8 statu quo.
- Plan B is essentially introducing message indirections

Advantages of plan B I see for the future:
- cleaner separation of concerns
- less vulnerable to refactoring (thanks to messages indirection)
- compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...)
easier thru messages

Last, I do not desesperate to sell plan B  to other forks.
See the outline pf plan B below.

So do you still buy plan A ?

Nicolas


------------------------------------------
    OUTLINE OF PLAN B :
------------------------------------------

PART I - Fusion of the 2 APIs in 1
1) add a globals instance variable to SmalltalkImage
2) initialize this instance variable SmalltalkImage current globals: Smalltalk
3) implement SystemDictionary methods in use to SmalltalkImage, and
redirect them through globals
MessageSentToGlobalFinder testMessagesSentToSmalltalk may help
4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current.

PART II - Refactoring
1) add a few messages in SmalltalkImage (vm ^self)
2) refactor users of SmalltalkImage current -> Smalltalk vm (or
Smalltalk commandLine or...)
This is the compatibility layer which will enable cross fork compatibility

PART III - Provide cross fork compatibility layers:
simple, Cuis and Pharo and Squeak3.8 and... just have to respond to
Smalltalk vm (and a few others)
either ^self or ^SmalltalkImage current or whatever they prefer

PART IV - deeper refactorings
1) split SmalltalkImage at will (no precipitation good Rationale SHALL
be provided).
2) introduce other Smalltalk hooks for not so well known classes
(SystemNavigation / SourceFiles etc...)

On 3/3/2010 3:30 PM, Nicolas Cellier wrote:
> For now, plan A has more votes than plan B.
> plan A: move all SmalltalkImage methods back into SystemDictionary in trunk.
>              Let SmalltalkImage current ^Smalltalk for crossfork compatibility
> plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class =
> SystemDictionary.

Just to be clear: My option #2 only goes until here. I'd like to make
some actual progress in the near term and your proposal is quite a bit
of mid- or long-term stuff.

> Advantages of plan B I see for the future:
> - cleaner separation of concerns
> - less vulnerable to refactoring (thanks to messages indirection)
> - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...)
> easier thru messages

Unfortunately that's all pretty much conjecture or even plain wrong.
Cleaner separation of concerns is a claim. It's actually *just* the
claim that was made about SmalltalkImage current and see where that has
gotten us. So let's try to be careful claiming victory before things
have even started. Less vulnerability to refactoring won't be happening
this way either - it's no less vulnerable to get a DNU than it is to get
an Undeclared. The same goes for the compatibility claim.

The *real* gain regarding refactoring and compatibility will be by
restoring Smalltalk as the facade that receives those various messages
and then passes them on to whatever the actual implementation site is.
Basically we need to be promising that we'll support Smalltalk as a
facade for all the stuff that SystemDictionary/SmalltalkImage support
today, but that we won't promise where it'll be implemented in the
backend. This way we have room to experiment with various locations and
anyone who needs the compatibility knows there is a safe, idiomatic way
of doing all this stuff via Smalltalk. The people who want to experiment
can do that and we can see what we like and dislike.

In other words, there needs to be a very clearly cut line: If you need
compatibility, you use e.g., Smalltalk allClasses, Smalltalk
vmParameters, Smalltalk garbageCollect. If you don't, you're free to use
Namespace default allClasses or VirtualMachine current parameters or
System soleInstance garbageCollect or Smalltalk vm parameters or
Smalltalk namespace allClasses. All of these can be delegated trivially
to from the Smalltalk facade making it very easy to provide the
necessary level of compatibility while leaving room for innovation.

Cheers,
   - Andreas

2010/3/4 Andreas Raab <[hidden email]>:
Yes I should have told this.
If you stop at B.II you already get compatibility with current forks.
So you can take a pause for a while a think twice.

This is a wise position.
I particularly like the "leaving room for innovation".
B.III - B.IV is compatibility with future evolutions.

Nicolas

> Cheers,
>  - Andreas
>
>

On 04.03.2010, at 00:30, Nicolas Cellier wrote:
Both Cuis and Squeak 3.8 support using Smalltalk over SmalltalkImage. In 3.8 the SystemDictionary methods were not removed, just deprecated.

- Bert -

Folks -

I've been working on this stuff a little now and (as always) things look
different once you actually dug into it. There is a really interesting
option here which I'd like to propose as option #3 since it does require
a bit of refactoring but it makes good sense to me:

* Move methods from SystemDictionary to SmalltalkImage.
* Make SmalltalkImage current == Smalltalk.
* Make Smalltalk globals class == SystemDictionary

So far we're still with option #2, but now it gets interesting:

* Use Smalltalk globals as Behavior>>environment, i.e.,

Behavior>>environment
        "Return the environment in which the receiver is visible"
        ^Smalltalk globals

* Remove any non-dictionary stuff from SystemDictionary; fix all
non-dictionary uses of "self environment" (VERY few; much less than I
expected)

* Remove all the dictionary methods from SmalltalkImage except #at:,
#at:ifAbsent:, #at:ifPresent: (there simply are too many users of those
to get rid of it but it avoids literally some 20+ methods that are
required otherwise)

The result is that:
1) Smalltalk == SmalltalkImage current
2) Smalltalk class == SmalltalkImage
3) Smalltalk globals class == SystemDictionary
4) SomeClass environment == Smalltalk globals

Interestingly, this is pretty much the way these entities are already
used; just not consistently. After browsing through quite a bit of code
that does feel like the most natural separation - the environment as the
dictionary / namespace; Smalltalk as the system-wide facade for various
things.

What do you think?

Cheers,
   - Andreas

On 2010-03-04, at 8:24 PM, Andreas Raab wrote:

> The result is that:
> 1) Smalltalk == SmalltalkImage current
> 2) Smalltalk class == SmalltalkImage
> 3) Smalltalk globals class == SystemDictionary
> 4) SomeClass environment == Smalltalk globals
>
> Interestingly, this is pretty much the way these entities are already used; just not consistently. After browsing through quite a bit of code that does feel like the most natural separation - the environment as the dictionary / namespace; Smalltalk as the system-wide facade for various things.
>
> What do you think?

+1

Colin

On 5 March 2010 06:24, Andreas Raab <[hidden email]> wrote:
That's pretty much what i envisioned.

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

> The result is that:
> 1) Smalltalk == SmalltalkImage current
> 2) Smalltalk class == SmalltalkImage
> 3) Smalltalk globals class == SystemDictionary
> 4) SomeClass environment == Smalltalk globals

looks good

Stef

Yes, yes, yes

Nicolas

2010/3/5 Andreas Raab <[hidden email]>:

On 05.03.2010, at 05:24, Andreas Raab wrote:

After all this discussion I realized I'm basically fine with any solution that allows me to write "Smalltalk" instead of "SmalltalkImage current" so this one sounds good, too. And it may lead to nicer separation of concerns down the road so +1 from me.

Can we also deprecate "SmalltalkImage current"? I'd not be sad if I'd never have to see that expression again - for aesthetic reasons, not because I don't like refactoring :)

- Bert -

On Fri, Mar 5, 2010 at 13:53, Bert Freudenberg <[hidden email]> wrote:
> After all this discussion I realized I'm basically fine with any solution that allows me to write "Smalltalk" instead of "SmalltalkImage current"

+1

> Can we also deprecate "SmalltalkImage current"? I'd not be sad if I'd never have to see that expression again - for aesthetic reasons, not because I don't like refactoring :)

+1

Folks -

After the positive feedback I went ahead and implemented the plan. Sorry
for the commit-spam, but it's all in place now, meaning:

1) Smalltalk == SmalltalkImage current
2) Smalltalk class == SmalltalkImage
3) Smalltalk globals class == SystemDictionary
4) SomeClass environment == Smalltalk globals

A special place in heaven will be reserved for Nicolas' little script to
find all the messages sent to Smalltalk without which fixing all the
dictionary accesses would have taken ages. Thank you, thank you, thank you.

I have deprecated several dictionary methods in SmalltalkImage instead
of removing them since some of them were heavily used and may very well
show up in external packages. Others were used by binary storage
(SmartRefStream, ImageSegment) and have been tagged as such. I'd be
interested in people trying to load binary stuff that has been written
before the change to ensure this all works as expected.

I have also taken the liberty to remove some cruft from SmalltalkImage -
methods that were literally ten years old, not called, and not serving
any observable purpose. If you miss one, let me know and we'll restore
'em but SmalltalkImage and SystemDictionary look much nicer without them
(check 'em out; it's pretty sweet).

I believe everything is healthy and in good working order but if you
find bugs, let me know. There's always the possibility of something
going wrong.

I'll leave the pass on converting SmalltalkImage current -> Smalltalk
for someone else :-)

Cheers,
   - Andreas


On 3/4/2010 8:24 PM, Andreas Raab wrote:

On Fri, Mar 05, 2010 at 10:14:01PM -0800, Andreas Raab wrote:
> Folks -
>
> After the positive feedback I went ahead and implemented the plan. Sorry
> for the commit-spam, but it's all in place now, meaning:
>
> 1) Smalltalk == SmalltalkImage current
> 2) Smalltalk class == SmalltalkImage
> 3) Smalltalk globals class == SystemDictionary
> 4) SomeClass environment == Smalltalk globals

Very nice. Thanks for driving this to a productive conclusion.
Opening an object inspector on Smalltalk now shows something
much easier to understand.

Dave

Thanks, Andreas for pushing it forward.

On 6 March 2010 19:07, David T. Lewis <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

>>>>> "David" == David T Lewis <[hidden email]> writes:

David> Very nice. Thanks for driving this to a productive conclusion.
David> Opening an object inspector on Smalltalk now shows something
David> much easier to understand.

Wow.  Indeed.

Smalltalk now represents all the metaprotocol about the current image.
And yet, classic "Smalltalk at: #Behavior" still works.

Nice.  Very nice.  Elegant.

All the delegation methods are a little wonky (Smalltalk at: #foo => Smalltalk
globals at: #foo), but I can live with that.

Andreas, did you just copy the entire collection protocol, or did you find
them item by item?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

>>>>> "Randal" == Randal L Schwartz <[hidden email]> writes:

Randal> Andreas, did you just copy the entire collection protocol, or did you find
Randal> them item by item?

Oh, and the class comments for SmalltalkImage and SystemDictionary
need a bit of love now.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On Sat, Mar 06, 2010 at 09:24:19AM -0800, Randal L. Schwartz wrote:
>
> Oh, and the class comments for SmalltalkImage and SystemDictionary
> need a bit of love now.

How about this as a class comment for SmalltalkImage?

   "I represent the current image and runtime environment, including
   system organization, the virtual machine, object memory, plugins
   and source files. My instance variable #globals is a reference to
   the system dictionary of global variables and class names.

   My singleton instance is called Smalltalk."

Dave

>>>>> "David" == David T Lewis <[hidden email]> writes:

David> How about this as a class comment for SmalltalkImage?

David>    "I represent the current image and runtime environment, including
David>    system organization, the virtual machine, object memory, plugins
David>    and source files. My instance variable #globals is a reference to
David>    the system dictionary of global variables and class names.

David>    My singleton instance is called Smalltalk."

/me wipes tears from eyes

Yeah, that'll do. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion