Brendan Eich wrote: [...] > I finally found time to write up a proposal, sketchy and incomplete, but > ready for some ever-lovin' es-discuss peer review ;-). > > http://wiki.ecmascript.org/doku.php?id=strawman:catchalls
# Catchalls are sometimes thought of as being called for every # access to a property, whether the property exists or not. The ability to define 'has', 'get', and 'invoke' handlers for the case where the property exists, is definitely needed IMHO. Suppressing the visibility of a property is potentially as useful as creating a "virtual" property, especially for the secure JS subsets. I agree however that this is only needed for some use cases, and for those case in which it is not needed, it would be inconvenient (and less efficient) to require has/get/invoke handlers to perform the default action. Defining 'has' and 'hasMissing', 'get' and 'getMissing', etc. appears to solve this problem, and I think that the extra complexity is justified. (Defining both the "always" and "missing" versions of a handler in the descriptor is not useful, and could be an error.) # Defaulting: sometimes a catchall wants to defer to the default # action specified by the language’s semantics, e.g. delegate to a # prototype object for a get. The ES4 proposal, inspired by Python # and ES4/JS1.7+ iteration protocol design, provided a singleton # exception object, denoted by a constant binding, DefaultAction, # for the catchall to throw. This can be efficiently implemented # and it does not preempt the return value. This means that "throw e", where e might have come from an unknown source, has to be avoided in a handler in favour of something like "throw e === DefaultAction ? new Error() : e". Yuck. # Runaway prevention: should a catchall, while its call is active, # be automatically suppressed from re-entering itself for the given # id on the target object? I think that all catchalls on a given object O, not just those for the same id, should be suppressed when handling a catchall for O. If you want the behaviour that would occur as a result of triggering a catchall for another property, then it is easy to inline that behaviour in the handler. But if you want to suppress the catchall behaviour for another property while in a handler, then it would be difficult to do so under the semantics suggested above. (Also the per-object suppression is easier to specify; it just requires an [[InCatchall]] flag on each object.) -- David-Sarah Hopwood ⚥ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
