Discuss
  • strawman:catchalls?

strawman:catchalls?

# Peter Michaux (17 years ago)

I don't see anything in the strawman wiki pages about a catchall method for an object. I think this is something that is really missing from the language and would substantially change the way some programs are structured.

The only ways I know of to currently get the equivalent behavior to a catch-all now is to either make objects as functions of their messages, or to make a "send" function. Both of these options mean leaving the standard object.message(a, b, c) message-passing syntax behind and use object("message", a, b, c) or send(object, "message", a, b, c) syntax. Both of these are substantially slower (though infinitely and enjoyably flexible.)

Are catchalls candidates to be added to the strawman pages?

Peter

# Jeff Watkins (17 years ago)

I'd absolutely second the catchall request. I currently jump through
nasty hoops or restrain my designs simply to avoid the lack of this
capacity. And if there were equivalents to valueForMissingKey and
setValueForMissingKey in addition to a function catchall, that would
be even better.

# Zachary Carter (17 years ago)

There was some talk about it in August here1 and here2.

Best,

Zach Carter

# ihab.awad at gmail.com (17 years ago)

On Wed, Nov 19, 2008 at 11:43 AM, Jeff Watkins <watkins at apple.com> wrote:

I'd absolutely second the catchall request.

+1. Catchalls allow one to implement a generic forwarding proxy. Two examples of usage:

  1. A generic "future" object that enqueues requests sent to it, returning a "future" for the result. Right now, Tyler Close's ref_send library in JavaScript:

waterken.sourceforge.net/bang

requires explicitly reified message sends:

drum_.post('bang', [ 2 ]);

whereas, with generic futures, it could simply be:

drum_.bang(2);

  1. An object whose implementation is changed at runtime. E.g. to support schema evolution and persistence (faulting in from stable storage upon invocation).

Ihab

# Peter Michaux (17 years ago)

On Wed, Nov 19, 2008 at 11:43 AM, Jeff Watkins <watkins at apple.com> wrote:

I'd absolutely second the catchall request. I currently jump through nasty hoops or restrain my designs simply to avoid the lack of this capacity. And if there were equivalents to valueForMissingKey and setValueForMissingKey in addition to a function catchall, that would be even better.

I think the catchall(s) need to be able to catch all these kinds of missing messages. API design is always a matter of taste. For example, should the API be made high-level, less verbose to use and give up some flexibility OR should it be low-level, more verbose, and have more flexibility?

For this catch all situation, I think the API should be very low level. The programmer should be playing at the level where he is actually concerned with things like "[[Get]]" etc. I think there should only be one catchall method and the programmer of the catchall can branch on the arguments like "[[Get]]".

obj.catchAll('[[Get]]', 'foo'); obj.catchAll('[[Put]]', 'foo', 21); obj.catchAll('[[Call]]', 'bar', 1, 2, 3); ...

Yes the code inside the would be more verbose than separate catchalls for getters, setters, methods. The above, however, would allow a framework for a "nicer" API to be built in ES code (like, for example, Ajax libraries provide a framework for callbacks depending on response status code.)

I think this low-level control would help enable a self-hosting ES if a completely blank "object" was available: whatever the Object prototype object's prototype should be (rather than the current null.)

Peter