A stab at the sealer in E Ka-Ping Yee (ping@lfw.org)
Tue, 2 Nov 1999 16:57:35 -0800 (PST)

On Tue, 2 Nov 1999, Mark S. Miller wrote:
>
> An object with a single method. It is equivalent to

Thanks for the reminder.

Okay. How about this:

define BrandMaker make(name) {

define _key := [] 

        define EnvelopeMaker make(contents) {
            define Envelope {
                to printOn(out) {
                    out print(`<Envelope sealed by $name>`)
                }   
                to getContents(key) : any {
                    if (key == _key) {
                        contents
                    }   
                    else {
                        throw(UnsealingException(
                            "envelope not sealed by matching sealer"))
                    }   
                }   
            }   
        }

        define sealer {
            to seal(contents) : any {
                EnvelopeMaker make(contents)
            }
        }
        define unsealer {
            to unseal(envelope) : any {
                envelope getContents(_key)
            }
        }

        [sealer, unsealer]

}

Notes:

  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.
  2. I wandered through the E language documentation to find the proper syntax for throwing an exception, and at first thought that the lack of a "throw expression" section on the grammar page was an omission. Now i realize that "throw" must be a function object provided by the big bang, but you might want to make this more explicit on the grammar page. In general it was tricky to find the info i needed to throw the right kind of exception (no sealer documentation yet, throw signature not mentioned on grammar page, no UnsealingException signature until i went to the Java docs).
  3. In the above i am using the convention of a leading _ for private variables, often seen in C++. Perhaps this could be another useful sanity check: variables whose names begin with _ are never intended to escape outside the scope in which they were defined.
  4. The above is not tested in E. I just wrote it in a text editor (which happens to be vim with E highlighting :) ).

Does this work?