Hi Niko,

Although there isn't a Classbox/Changebox infrastructure in Self at the moment, the flexibility of Self should allow you to go some of the way.  You won't be able to automatically keep track of changes, but copying and keeping old versions of methods around while testing is a matter of drag and drop.

I'm lumping the Changebox stuff you refer to with their earlier Classbox stuff because keeping multiple versions of an object around is the same as keeping multiple implementations of compatible objects around - that is, versioning is really the same as modularisation.

The Classbox/Changebox etc stuff is a limited implementation of the type of stuff that 'Us' implemented: subjective, perspective based messaging systems (see http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.7535)  There isn't a publically available version of Us at the moment, though.

(If you are interested in this stuff you should look at Slate as well, btw)

Cheers,

Russell




Niko Schwarz wrote:
 

Hi!

I am interested in keeping several versions of code living side by
side in the same image. There is an implementation in Smalltalk, but
I'd like to know if this could be done more elegantly using Self.

The Smalltalk implementation is called Changeboxes,
http://scg.unibe.ch/archive/papers/Denk07cChangeboxes.pdf. It
essentially works by hooking into the compiler and then, upon every
method compilation, NOT pushing the Class onto the stack, but rather a
level of indirection which finds the correct version of the class.

The idea is essentially the following. Imagine you just built a
feature, and it works, let's say you just implemented Exponentiation
using a while loop, that just multiplies a number with itself a given
number of times. It works. But you find it slow. Now, you fork, and
keep the old version around. You change the method, right there, you
don't make a new method, you CHANGE the old one. But still, you keep
the old one around.

And then you run them side by side. The currently active branch might
be the sped up algorithm, but you can still access the main trunk, so
now you benchmark the two, and see if they yield the same results:

[2 raisedTo: 100 ] timeToRunAndResult
[[2 raisedTo:100] inBranch: #main] timeToRunAndResult

So, how would you implement this version change with only little
performance penalty? How does the lookup process work anyway and how
can I hook into it?

All the best,

Niko

raisedToThe: anInteger
|res|
res := 1.
anInteger timesRepeat: [ res = res * self]
^

but it is slow. Now you fork, and keep the working version around,
both for examination