Improving ECMAScript as a compilation target

[Allen Wirfs-Brock]

My comfort level in this starts to fall significantly as we get into the hit or miss space.  That is the point it suddenly feels like it is trying to be (or should be trying to be) a complete meta-object protocol rather than just a reification of failed property accesses. The former is interesting but I think it is much harder to justify, design, and efficiently implement than the latter.  For now, I'm not convinced that we have a compelling need for the full meta-object protocol. If nothing else designing a simple catch all handler model is good practice for designing a full MOP.

Other than creeping toward being a MOP, my main concern is that the current design proposal just feel like it is getting too complex (needing to know which are hit or miss only operations, needing to understand how language level operations decompose into sequences of meta level operations).  In addition, I think the terminology should better reflect the common user level understanding of the language.  

A simpler model would only have these handlers
	assign	called on any explicit assignment to a non-existent property
	invoke	called on any call to a non-existent property
	construct	called anytime new is used with a non-existent property
	delete	delete a non-existent property
	getValue	called on any implicit or explicit non-existent property access to that is not one of the above  

At most one of the above is called on any property reference, and only if the property does not exist. I thought a bit about various schemes for dealing with catch alls along the prototype chain but the complexity rapidly grows. I concluded that it is probably better to just let a handler set implement its own prototype lookup logic if it wants to allow for prototype inheritance of catch all provided properties (that also supplies a use case for Object.create(null))

Does this provide enough to support your E4X scenario?

Allen


>-----Original Message-----
>From: Brendan Eich [mailto:brendan at mozilla.com]
>Sent: Tuesday, May 05, 2009 11:32 AM
>To: Allen Wirfs-Brock
>Cc: es-discuss Steen
>Subject: Re: Improving ECMAScript as a compilation target
>
>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