[squeak-dev] Immutability (was Re: About String vs Symbols)
tim at rowledge.org
Tue Jul 29 21:51:50 UTC 2008
On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:
> What I'd like to do is modify Slang so that one can mix and match
> components to produce the VM you want. In the StackVM I'm working
> on I already have the ability to add a subclass that overrides
> methods in the superclass so NewObjectMemory organizes the young
> generation differently to ObjectMemory overriding a few methods. It
> should be easy to extend this to allow e.g. ImmutabilityInterpreter
> to override Interpreter and add immutability without having to
> rewrite the entire Interpreter class.
I'm fairly sure that should have worked without any extra work since
it is essentially how the codegen works anyway. What *doesn't* work is
adding subclass and being able to use 'super' to only slightly modify
the superclass code. I tried to get it working some years ago in an
attempt to make it easy to implement OS specific plugin classes more
easily but it drove me too close to the edge of insanity for my
liking. If you've got *that* working I'd be very pleased.
Another aspect of pick'n'mix I'd like to see working is having all the
parts of the vm in plugin (or plugin-like) modules. Why insist on
having the GC irrevocably bound into the core (just for one example)?
Why not have a system that can startup with no GC code; let the
image's policy decide which GC plugin to load dependant upon need. An
ephemeral app invoked to do a tiny job and quit may need no GC
functionality at all so why waste space and setup time? A server app
might want to use a much more sophisticated GC than our typical
desktop system. Or perhaps the system should start up and run as a
simple interpreter for a while until a policy has decided that Eliot's
translator plugin should be loaded. And so on.
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Oxymorons: Soft rock
More information about the Squeak-dev