| Store | Cart

Re: more thoughts on op_sibling

From: Zefram <zef...@fysh.org>
Sun, 26 Apr 2015 19:41:06 +0100
Dave Mitchell wrote:
>Ok, the proposal becomes:>>    On both non-PERL_OP_PARENT and PERL_OP_PARENT builds,>    op_sibling_splice() will work with a null parent arg, as long as the>    first and last ops in the op_sibling chain remain unchanged. It will>    croak if not supplied with a parent pointer and what constitutes the>    first or last op in the chain would change.

With these restrictions, the null-parent-arg operation is a rather
bizarre shape that doesn't sit well with the type of operation that
op_sibling_splice() is mainly intended for.  It should probably be a
separate API function, not a crowbarred-in variant of the existing one.

We got into this from talking about the case where an op chain has no
parent op.  I think it would be sensible to have functions to manipulate
that kind of chain.  We've naturally gravitated towards trying to
treat that case just like children of a parent op, just without an
actual parent, but I think that really doesn't work.  The links that
are available between the nodes are sufficiently one-way that we can't
get away with the code not knowing a priori which situation it's in.

In the existing op_sibling_splice(), I'm uneasy about how the op_last
logic, and I think this boils down to it failing to handle OP_CUSTOM
properly.  It should be using OP_CLASS() rather than examining PL_opargs[]
directly.

-zefram

Recent Messages in this Thread
Dave Mitchell Mar 30, 2015 01:48 pm
Zefram Mar 30, 2015 03:30 pm
Dave Mitchell Apr 01, 2015 04:19 pm
Zefram Apr 01, 2015 05:01 pm
Dave Mitchell Apr 08, 2015 02:32 pm
Dave Mitchell Apr 18, 2015 09:34 pm
Dave Mitchell Apr 19, 2015 06:37 pm
Zefram Apr 26, 2015 06:41 pm
Dave Mitchell Apr 27, 2015 01:08 pm
Zefram Mar 25, 2015 01:32 pm
Messages in this thread