[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: name for SEFTable
- To: <mark>
- Subject: Re: name for SEFTable
- From: Michael McClary <michael>
- Date: Sat, 28 Oct 89 07:20:20 PDT
- Cc: <tribble>, <xtech>
> 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;
> 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.,
> 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