[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
name for SEFTable
- To: <michael>
- Subject: name for SEFTable
- From: Mark S. Miller <mark>
- Date: Sat, 28 Oct 89 14:41:56 PDT
- Cc: <tribble>, <xtech>
- In-reply-to: <Michael>,20 PDT <8910281420.AA16823@xanadu>
Date: Sat, 28 Oct 89 07:20:20 PDT
From: michael (Michael McClary)
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.
On reflection, if I understand the language correctly, I think they
did a good job here. Inside a const method, one may not change the
internal state of the object *unless one casts "this" to non-const*.
Such a cast serves to explicitly flag the programmers belief/claim
that this is an internal state change without externally visible
effect. As such claims are inherently suspect, having the language
catch the non-casted cases looks good to me.
I haven't tried any of this, and haven't read this section of the
manual for a while, so I'm not sure any of the above is accurate.