develooper Front page | perl.perl5.porters | Postings from February 2018

Re: [perl #132810] Blead Breaks CPAN:KYZ/Test-MockCommand-0.03.tar.gz

Thread Previous | Thread Next
Sawyer X
February 5, 2018 14:27
Re: [perl #132810] Blead Breaks CPAN:KYZ/Test-MockCommand-0.03.tar.gz
Message ID:

On 02/05/2018 03:32 PM, Leon Timmermans wrote:
> On Mon, Feb 5, 2018 at 1:50 AM, Father Chrysostomos via RT
> <> wrote:
>> On Sun, 04 Feb 2018 13:14:09 -0800, LeonT wrote:
>>> This essentially changed the prototype of a keyword. I don't think
>>> that sort of breaking change should happen without a proper discussion
>>> about it.
>> But the previous behaviour would mess up the stack.  And readpipe’s own arguments would be evaluated in one context one time and another context another time.  That’s clearly a bug.
> It is clearly a bug. I wasn't arguing for a revert, I'm arguing for a
> different fix.

You're making two arguments:

1. Different technical solution.
2. Not making such a change without further "proper discussion" about it.

I think there is always room for improved technical solution and little
argument about that. I am not in a position to evaluated your suggested
improved solution below but I would like others to do so. If there is a
better solution, let's take it.

As for the second problem, I think you make a good point there too. I
was wondering what the documentation says because that's at least
something to lean on in the discussion. If the documentation says "This
is how you use this," then we have some room (taken very loosely here)
in making it work the way we promise. With less room we would need to
unfix it and change the documentation to reflect "Sorry, it isn't the
way we said it would be. It is this way."

The documentation for readpipe() does not explain the input except
"EXPR". It does point to qx() and that documentation indicates the input
for qx() is a string. This also point to "I/O Operators" for further
reading. perlop contains that part but that doesn't seem to shed more
lights on the input of qx() or readpipe().

We could interpret this as "We didn't declare what you can't do, so all
bets are off" (which is sometimes the case) or "We should indicate in
the documentation what should happen and at least now we're checking for
it." I'm honestly not sure on which case we fall here. I think the
ability to resolve this technically could help yield a different outcome.

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