Catchall proposal

David-Sarah Hopwood david-sarah at
Wed May 6 08:22:52 PDT 2009

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 ;-).

# 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 ⚥

More information about the es-discuss mailing list