Getting Ready

Alexandre Bergel bergel at iam.unibe.ch
Mon Mar 7 18:11:17 UTC 2005


Hi David!

Sorry to answer so lately to your email. I was away until today.
I see that assigning one method cache per project/module/workspace/whatever is only as an implementation trick to implement a model.

What is the model behind Sonora ? how do you handle method redefinition ? 

With classboxes, I have the following SUnit assertions:

cx1 _ self createClassboxNamed: #CX1.
cx2 _ self createClassboxNamed: #CX2.
"---------------------------"
cx1 import: #Object from: Classbox system.
cx1 createClassNamed: #TestCXA.
cx1 createClassNamed: #TestCXB superclass: #TestCXA.
cx1 addMethod: 'foo ^ 1' for: #TestCXA.
cx1 addMethod: 'bar ^ self foo' for: #TestCXB.
"---------------------------"
cx2 import: #TestCXA from: cx1.
cx2 import: #TestCXB from: cx1.
cx2 addMethod: 'foo ^ 2' for: #TestCXA.
"---------------------------"
self assert: (cx1 evaluate: 'TestCXB new foo') = 1.
self assert: (cx1 evaluate: 'TestCXB new bar') = 1.
"---------------------------"
self assert: (cx2 evaluate: 'TestCXB new foo') = 2.
self assert: (cx2 evaluate: 'TestCXB new bar') = 2.


Other tests are available on http://kilana.unibe.ch/classboxes/tests/ and a tutorial containing screenshots is available on http://kilana.unibe.ch/classboxes/classboxtutorial/

Alexandre

On Tue, Mar 01, 2005 at 09:48:31AM -0700, David Farber wrote:
> 
> 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

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



More information about the Modules mailing list