[e-lang] Re: On kernel-E, operators, and properties (part 1)
david.nospam.hopwood at blueyonder.co.uk
Thu Apr 8 10:57:21 EDT 2004
> expr1<-name := expr2 --> expr1<-&name<-setValue(expr2)
This expansion has some consequences I hadn't considered. The two
send operations in the expanded code are not atomic, so if it is
possible for a given property slot to change to a different slot
object, updates could be lost:
bar.&foo is initially slot1. bar is in vat B.
vat A executes bar<-foo := baz
expansion of bar<-foo := baz saves slot1 in a temporary
vat B changes bar.&foo to slot2
expansion of bar<-foo := baz causes slot1.setValue(baz)
but slot2 never gets set to baz.
So this means that a property slot, once returned by __getSlot, cannot
reliably be changed to a different object.
> expr<-name --> expr<-&name<-getValue()
This is also not atomic, although it's less of a problem than the
lost updates issue above.
OTOH, I think it would be OK just to impose a correctness requirement
that the slot object for a given property does not change (in which
case, the difference between an expansion with one or two sends is not
observable). If it changed then that would almost certainly confuse
code that uses the slot explicitly, anyway.
Also, it's difficult to see why you would want to change the slot of
an existing property. Even upgrading the slot implementation does not
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the e-lang