[cap-talk] 'Destroy' vs 'Sever'

[David Hopwood]

From: Lex Spoon <lex at lexspoon.org>
> On Wednesday 21 November 2007 17:57:03 David Hopwood wrote:
>>  I don't know KeyKOS well enough to say whether there were compelling
>>  uses in that context; in general 'Sever' doesn't seem all that useful
>>  (no object language that I know of has a similar operation, although
>>  most have a convention of providing 'clone' for almost all objects).
>
> Just to state what might be obvious, 'sever' sounds to me like a
> simplified 'revoke' revoke the revocation pattern.  After calling
> sever/revoke, you know that anyone you passed the reference can no longer use
> their old reference.  So the presence of 'sever' means you can always revoke
> a reference, even if you did not set up a revoker ahead of time.

That's also true if 'Destroy' is available but 'Sever' is not.

The issue raised by 'Sever' is that the new reference it returns
will point to an object that may malfunction, as a result of not
receiving messages directed to the old object.

This is especially problematic when the object is part of a (nontrivial)
composite: the Sever operation will break "internal" links from other
objects of the composite to the severed object, but it won't destroy
or sever those other objects. The resulting behaviour will depend on
implementation details of the composite; it won't in general have a simple
explanation in terms of the composite's documented behaviour.

'Destroy' also won't destroy other objects in the composite, but it
will prevent the destroyed object from being invoked and from performing
any invocations. At the point at which another object of the composite
tries to invoke the destroyed object via an existing reference, it will
receive an error (typically reported as an exception at the language level),
which assuming it is not ignored, will abort the current "plan" of the
other object.

>> I have not delved into such systems enough to say whether you want this to
>> always be available on every reference.  One issue is that it is a really
>> simplified instance of the revocation pattern, so many users of the
>> revocation pattern will not be able to use this primitive.

Yes; both 'Sever' and 'Destroy' only work when the requirement is to
revoke *all* current references to an object.

[...]
>> An additional use would seem to be to help with an issue I've long wondered
>> about with the programmer's shell.  If you are a programmer monkeying with
>> your system, then you will sometimes write incorrect code.  I know, I know,
>> none of the present company, but some programmers do write incorrect code
>> sometimes.  In such a case, it would seem nice if the shell gave you some
>> sort of revocation available on all of the objects "owned" by that
>> programmer, so that they can get the system back into a sane state with no
>> leaked references.

'Destroy' seems to be sufficient for this.

-- 
David Hopwood