[self-interest] Keeping several versions around

[Russell Allen]

Hi Alexandre,

Great to see you're on the list - I'm a definate admirer of your work.

Getting a Classbox style module system on Self would be a fascinating  
project.  I'm not sure how feasible it would be in the short term,  
though.  Didn't you have to change the Squeak VM to get Classboxes on  
it?  What did you do for Java?

One fundamental question I have is whether a Classbox is possible on a  
prototype based system or whether you need to go the whole hog to Us.

Russell

On 01/08/2009, at 12:29 AM, Bergel, Alexandre wrote:

> Dear List,
>
> I like the discussion you're having regarding modularity and system
> extension. We had similar discussion in the Smalltalk World.
> It will be a pleasure to participate in discussion and provide help if
> necessary to have classboxes/changeboxes in Self.
>
>> 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.
>>
> Indeed
>> The Classbox/Changebox etc stuff is a limited implementation of the
>> type of stuff that 'Us' implemented: subjective, perspective based
>> messaging systems (seehttp://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.
>>
>
> Yes, the work done on Us is very similar to what have been done with
> classbox/changeboxes.
>
> Regards,
> Alexandre
>
>
>> 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
>>>
>>
>>
>>
>
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>