Re: name for SEFTable

[Michael McClary <michael>]

> From: mark (Mark S. Miller)
>    Date: Thu, 26 Oct 89 14:05:12 PDT
>    From: michael (Michael McClary)
> 
>    > From tribble Wed Oct 25 17:36:58 1989
>    > 
>    > note that C++ uses 'const' incorrectly.  You can have a 'const'
>    > pointer to an object that change state because another object has a
>    > non-const pointer.  That's why immutability is different from 'const'.
>    > An immutable object can't have its state changed at all.
> 
>    I agree that that's what it does, but I don't agree that it's
>    incorrect.  "const" applies exactly to what it is applied to.
>    A "const" pointer is a pointer that may not be changed, which
>    says nothing about the object it designates.  You would point
>    to a const object with a const pointer by saying:
> 
> 	   const ConstType * doubleConstP;
> 
>    while
> 
> 	   ConstType * constTypeP;
> 
>    would be a variable pointer to a const object, and so on.
> 
> I think the interesting case is:
> 
> Baz *const p;
> 
> This means that the holder of the pointer cannot modify the object
> being pointed at if he accesses it through the pointer.  I.e., 
> 
> p->foo();
> 
> is only allowed if foo() is a const member function of Baz.  If he
> also has an unconstrained pointer to the same object, he can modify it
> through that path, and see the effect via messages on p.  I actually
> think that this is the right semantics for the construct.  I just
> think that "const" may not be a very good name for it.

Hey, is "static" a good word for "name not exported to other modules"?
Nevertheless, I agree that "const" is not a good name.  In particular:

As I understand the talk with Dean (yesterday), we have three cases
for the object itself (a separate issue from the const-ness of the
pointer to it):

	client	other clients	Named
	------	-------------	------
	rw	rw		MuTable
	r-	rw		ScruTable
	r-	r-		ImmuTable

The C++ "const" constructs have the advantage that the compiler
enforces the programmer's intentions, but appear to have the
disadvantage of not distinguishing the first two cases in any
way that lets a client assure itself which it holds.

They also have the disadvantage that the compiler constraints
appear to be a protruscian bed, preventing us from writing virtually
read-only objects that actually change state in ways invisible to
their clients.

	michael