Improving ECMAScript as a compilation target

[Brendan Eich]

On May 5, 2009, at 12:26 AM, Brendan Eich wrote:

> Still, as noted for delete above, full virtualization might want  
> every- and first- forms of all of the hooks. Instead of the add/set  
> split I wrote up, we could drop add and split all the hooks in two,  
> burdening the uncommon case with the longer name (everySet and set;  
> blech). I'm resisting this, it feels overdesigned, besides making  
> for ugly names.

The current design tries to distinguish hooks run for every access  
(whether or not the property exists) from those run only if the  
property does not exist:

hit or miss:   get, set, delete
miss only:     has (before get), add (before set)
miss at least: invoke, construct

Thus has : get :: add : set. If you want a hook that is called when a  
property not in the object is about to be the subject of a get, use  
has. If you want to hook into property creation via set of an id for  
which no property exists in the object, use add. In any case, get and  
set are always called.

The symmetry breaks because DefaultAction for set is to create the  
missing property, whereas for get it is to return undefined. But this  
symmetry break could help minimize the API and avoid a "has" hit/miss  
hint arguments, getHit/getMiss, etc., hooks.

Because of its boolean result, delete should probably be called  
whether or not the property exists. Again this design intentionally  
shies away from deleteHit/deleteMiss hook bloat.

The case for invoke based on __noSuchMethod__/doesNotUnderstand/ 
method_missing is analogous to has for get and add for set. But again  
this does not allow self-hosting E4X (something you may not care  
about, but I do, since SpiderMonkey's E4X implementation should be  
self-hosted to reduce code size and attack surface) and things like  
it. There's no corresponding "hit or miss", always-called hook for  
invoke, if we stick to this course.

I surmise that construct is in the same category as invoke, but I  
could be wrong.

Alternative scheme, which still avoids requiring method cons'ing/ 
memoizing:

hit or miss: get, set, delete, invoke, construct
miss only:   has, getMiss, setMiss, deleteMiss, invokeMiss,  
constructMiss

Rationale: has is still useful when we do want to reify for whatever  
reason; invokeMiss is __noSuchMethod__; the short names work for the  
universal if not always-most-common cases.

/be