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
