Re: [PATCH v4 3/9] add target method delegation

[Tom Tromey <tromey at redhat dot com>]

Tom> But looking more closely at the code on the branch, there is an
Tom> assertion in those methods returning something other than void.

Tom> I'll think about it some more.

I looked at all the delegation functions today.

I think it would be fine to make nearly all of them assert.

The two exceptions are target_delegate_xfer_partial (already does not
assert) and target_delegate_wait (which does assert but which I think
should not).

In all other cases there is either a de_fault call for the method, or
the dummy target implements the method.

target_delegate_wait is a tricky one, as it returns a value.  Perhaps
just throwing an exception is best.  The current code isn't much of a
guide because it throws the exception when the record target is pushed
-- but as noted in the thread, this is not robust as the target stack
can change even after a target is pushed.

Your comments on this would be much appreciated.


Some thoughts the target vector.

I think the underlying problem here is complex, so it is reasonable if
the model is as well.  That is, I think it's fine to combine inheritance
(e.g., the various linux-* vectors) with delegation (the whole stack
itself plus special hacks in record and maybe elsewhere).  That in
itself is tractable.

However, I think the combination of using INHERIT, plus de_fault, plus
the dummy target, plus special wrappers for some target APIs leads to
madness.

It's much too hard to navigate this.  I think we should adopt some
simpler rule.

Tom