A stab at the sealer in E
Tue, 2 Nov 1999 19:56:11 -0800 (PST)
On Tue, 2 Nov 1999, Mark S. Miller wrote:
> > 1. This is personal, but it seems surprising that "==" means
> > object identity here, and i can imagine a novice asking
> > "Why can't i get the contents of just any envelope with
> > envelope getContents()?" I'm very hooked on Python's
> > "is" and "is not" operators.
> You'll have to remind me about Python's equality semantics. Not knowing
> which is Python's object identity operation, or what the other means, I did
> not get the point of your comment.
Sorry. I am used to "==" being an "equals" that depends on the
object (as in C++, Python, Perl) and "is" being the same-identity
operator. You can define a method to implement "==", but you can't
escape "is". "is" is "is"... if two things are "is", they are one
and the same object. (Sorry, i'm having perverse fun with grammar
> You are correct. The state of documentation on the E language still sucks.
My comment was not intended as direct criticism, just pointing out
places where a little filling in might be good.
> I like the idea of having such a convention. In fact, I like it a lot!! My
> immediate reaction is that I hate leading "_" as a convention, but maybe I
> would get used to it.
Not sure. I guess it is kind of strange-looking, but the idea of
having to capitalize a variable just to make it private seems even
more repulsive, and we don't have any other choices besides _ and
... for a naming convention anyway. I suppose one might consider
a declarative notation like
define private key := ...
private key := ...
define secret key := ...
secret key := ... # avoids confusion with C++/Java "private"
but that requires more thought on semantics -- is it straightforward
to see what the compiler/interpreter should do? Hmm. I guess it
Hmm. Declaration is easier to read than a naming convention,
but a distinctly-named variable is easier to spot buried in
code. Does the latter concern become less relevant if we can
rely on a compiler to do the check? Calling things "secret"
has a definite aesthetic appeal to me...
> "" evaluates to a ConstList.
Oops, yes, i expected it to be mutable. More Python heritage
showing... s are mutable lists, ()s are immutable lists.
> The problem is that the unsealer is giving the alleged envelope the key it
> is supposed to keep secret. In fact, you could have caught this security
> breach using your own suggested convention! The line
> "envelope getContents(_key)" visibly passes out a variable that starts with
> an underbar.
Man, i feel *so* stupid. :) Of course, you are quite right.
See my other message for a second attempt.