develooper Front page | perl.perl5.porters | Postings from November 2005

Re: [PATCH] sort/multicall patch

Thread Previous | Thread Next
Robin Houston
November 6, 2005 10:54
Re: [PATCH] sort/multicall patch
Message ID:
On Sun, Nov 06, 2005 at 02:08:02PM +0000, Dave Mitchell wrote:
> That's a point. In that case, I'd be tempted to leave PUSH_MULTICALL as-is
> rather than doing fancy tricks.

You've got me all confused now! :-)

Purely from the perspective of the XS module author, the parameterised
interface (PUSHSUB(cv)) is more comprehensible than the implicit-cv
interface; I guess you agree with that?

So it's an implementation question: do two wrongs make a right?
In other words, should we use evil macro-abuse to protect the 
innocent module author from perl's evil macro abuse? Or is it
just needless complexity?

I tend slightly to the view that the author should be protected,
but I'm pretty ambivalent about it. What's your reasoning?

> I haven't looked closely at the code, but wouldn't it be possible to
> factor out the common code into a macro (which needn't be part of the
> public API) then have the public macros use them, eg
> #define PUSH_MULTICALL \
>     ....
>     ....
> (he says vaguely handwaving).

I'm sure something like that would be possible, but it's different
enough that it would be quite convoluted. For example, you can't
call PUSHSUB without a CV, so pp_sort() actually uses a CXt_NULL
instead of a CXt_SUB in that case. If you're going to do that,
you also need a PUSHSTACK/POPSTACK pair, or else return() in the
sort block would return right out of the containing sub. (It
works at present because dopoptosub() only looks within the
top-level stack.)

It's the usual perl internals story really: everything depends on
everything else in mysterious and undocumented ways, and it's
hard to make apparently innocent changes without subtle breakage...


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About