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

"One user expectation, fed and watered by E4X, is that methods are not properties, or to avoid this JS oxymoron, that methods are not in the default property namespace:
js> x = <room><width>12</width><length>16</length></room>
<room>
  <width>12</width>
  <length>16</length>
</room>
js> x.length
16
js> x.length()
1
[snip]

The other possibility, at least for invoke, is that the handler is invoked whenever an attempt is made to call the value of an non- existent property of obj.

The general intention for catchalls is to call the action hook only when the property is missing.

This is certainly true of __noSuchMethod__ from SpiderMonkey, inspired by doesNotUnderstand in Smalltalk (which spawned method_missing in Ruby), but the E4X <room> snipped above shows a counter-example. There, even though 'length' names a "property" (E4X is so strange that the scare quotes are justified), we want to treat invocation of length as different from a get followed by a call of the got value.


The odd case is set, vs. add in the strawman (or first-set vs. every- set in the prose).

That's one obvious exception. I clarified in the wiki how has, get, and invoke may also want to be called only for non-existent properties. Or not, if you are implementing E4X.

Even delete might want to be called for non-existent properties, to fake its boolean result based on existence of a peer property not yet reified.


There's a less common case of wanting every-get too, to filter results of and/or control access to existing properties.

This case we have had in SpiderMonkey's C API forever. It's generally a hazard where careless embedders end up running every property get through a class getter that does nothing useful and just slows down the access. We have to work around it in TraceMonkey when JITting. We'd like to break the API here, soon.

Not sure how much of a lesson this gives, but I suspect every-get is going to be the uncommon case for catchall users.

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.

Comments from Caja, Web Sandbox, and other such folks are more than welcome here.

/be

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to