Getting Ready

[David Farber]

At 11:11 PM 2/28/2005 -0800, you wrote:
>Now imagine that the VM can have multiple method caches, one per, um, per process?  per module?  Think about it.  And when you have figured it out, note that this system could run simultaneous multiple projects with conflicting changes to root classes with no performance degradation.

Dan - This is exactly what I want to accomplish with Sonora.

Imagine a Workspace that understands an extended syntax that lets you define methods and classes in addition to the normal code snippets.

----SonoraWorkspace
'Hello!' asRot13.

String>>asRot13
    ^self collect: [:ch | ch asRot13]

Character>>asRot13
    ((self >= $a) & (self < $n)) | ((self >= $A) & (self < $N))
        ifTrue: [ ^ (self asInteger + 13) asCharacter ].
    ((self > $m) & (self <= $z)) | ((self > $M) & (self <= $Z))
        ifTrue: [ ^ (self asInteger - 13) asCharacter ].
    ^ self

----

If you select all of the code above and 'PrintIt' you should get 'Uryyb!'.  The trick is, the two asRot13 methods should only be visible to messages and objects that originate from this invocation of the workspace.

So far, only the code that understands the extended syntax has been written.  To implement the "module" behavior I want, I was thinking about hacking in some ugly, behind-the-scenes, anonymous class manipulation.  Obviously, if we can come up with a cleaner, more general approach, that would be better.

david

--
David Farber
dfarber at numenor.com