On Sat, 2004-05-29 at 15:29, Dan Sugalski wrote:
> The problem with the first scheme is that anything that has a handle
> on the PMC will not get the new layers. Not a good thing.
I like the first scheme. The question that comes up is: when does
something get layered?
That is: if I have code that says:
new_thread_increment_every_minute(foo)
become_read_only(foo)
Then, you have two choices of semantic:
1. foo is read-only retroactively and will throw an exception in one
minute
2. You've given the new thread a read-write version of foo, and the
read-only version created after that now has the property of changing
every minute.
I would see this as being very useful for several types of read-only
access to data that DOES change (an accumulator for a random number
entropy pool, for example).
High level languages on the other hand, should probably not expose this
directly. They will create a variable and tag it as read only at the
same time, and to the programmer there's no difference.
If they do allow for run-time read-only-ification, they can always build
their own high-level abstraction around this core PMC.
The only problem I see with this is that high level languages might want
to cache the value of a read-only variable in a typed register. If read
only really is read only, that's valid, but if it's only an interface
restriction it's not.
There you're going to have some semantic boundaries between languages
that might be unfortunate. How much of a problem that is, I'm not sure.
As for threading, I think the simple layering is easiest, and again, you
create the PMC layered if you want that functionality (e.g. for
locking).
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
