I would like to do generic dispatching (allowing the programmer to
write their own dispatch function), but the most satisfactory scheme
I've come up with so far has a security hole.

Consider the following:

When you include a dispatch table in your object code, the loader
gives you back a mapping from method selectors to opaque invokables.
If you're writing a custom dispatcher, you have to have access to this
mapping, and presumably to the invokables themselves.  Normally, you
just hand the mapping off to a generic dispatcher written in RTF which
takes care of doing the actual invoking.

I'd like to allow direct dispatching to delegated objects, so we don't
have to do five hashtable lookups where one would suffice.  So, each
object state can store a set of objects which it delegates to.  The
method lookup would return not only the invokable, but also the index
into the delegate table.  The delegate table would have to be read
only.

Create an object called DangerMouse.  DangerMouse allocates an array,
and implements dangerRead and dangerWrite, which get passed through to
the array.  When dangerRead and dangerWrite are loaded, the array
accessing code gets inlined.  Since DangerMouse allocated the array,
and noone else ever writes to the array slot, the check for its
arrayness can be removed by the optomizer.

Now, obtain a File object.  The File object is known to contain within
it a powerful RootFile capability, which you would like access to, but
which is confined by the File object.

Create an object called WillRobinson, which delegates to the given
File object.  WillRobinson has a custom dispatcher.  You've obtained
the invokers to dangerRead and dangerWrite via another object with a
custom dispatcher.  Plug them in to WillRobinson.  Now you can call
dangerRead on WillRobinson which will proceed to access the File
object as though it were an array.  You use this to pluck the bits of
the RootFile capability out, and use dangerWrite to store them
elsewhere so you can use them.

There are a variety of ways of avoiding this problem, but I don't like
any of them:

1) Don't allow eliding of delegation dispatch.  Performance hit.

2) Detect when an invokable is directly accessible to the programmer
   and disallow the eliding of type checking.  This adds extra
   complexity to an already hard to understand optomizer.

3) Never elide type checking.  Performance hit.

4) Confine invokers to their class.  This seems to disallow generic
   dispatching.

Until I can figure out a way around this, I think generic dispatching
is the feature that needs to go.  *sigh*