[squeak-dev] Decoupling Interpreter <> ObjectMemory (Was: Winds of change)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Decoupling Interpreter <> ObjectMemory (Was: Winds of change)

Igor Stasenko
Hello list,

in the light of discussion about embedding & callbacks, i just
thinking, what if we decouple interpreter state from object memory
state?
In potential, then we could have multiple instances of interpreter
which can work with same object memory. Not concurrently, of course :)
This could give us a freedom in a way, that external application, at
any point of time can use own interpreter instance to make a message
sends and get results.
Lets not take a cost of refactoring into account by now :), i just
want to hear what you think it could give us from architectural
perspective.
Or, there is another/better alternatives to use squeak by external
application like in following C pseudo-code to work w/o much troubles:

class = vm.getClassByName("MyFoo");
object = vm.sendMessage(vm.symbol("new"), class);
result = vm.sendMessage(vm.symbol("dosomething:"), object, vm.smallInt(1));

--
Best regards,
Igor Stasenko AKA sig.