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:[email protected]]
>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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
