Re: I ran across this while working on the spec.

On Thu, Oct 17, 2013 at 1:06 PM, Abdelaziz Raji <abdelaziz.raji@gmail.com>wrote:

> e3eeeeeeeeeeeeeeèr
>

Cool story, bro.

I still like #1, shortly followed by #2, and I dislike the rest pretty much
equally.

#1 still seems the most clean to me conceptually, as it follows from the
fact that the static table entries take up no memory (although they still
have the overhead of the reference set membership) and they're not
evictable. In fact for consistency I'd prefer the calculated size of a
static table entry to be 32 (i.e., the "normal" size minus size(name) +
size(value)). This would account for any additional state other than the
reference set membership (e.g., how many times a static table entry was
explicitly emitted, etc.).

#2 has the advantage that it's explicit -- if clearing the context will be
a common operation compared to sizing the context to some non-zero size,
then perhaps we should just have an explicit operation for it instead of
going through contortions to try and make it possible implicitly. I dislike
it only because we probably *do* want to keep track of the overhead of the
static table entries.