develooper Front page | perl.perl5.porters | Postings from December 2017

Re: Request For Context - about the 5.22->5.24 context stack rework

Thread Previous | Thread Next
Sawyer X
December 17, 2017 14:55
Re: Request For Context - about the 5.22->5.24 context stack rework
Message ID:

On 12/13/2017 04:59 PM, Paul "LeoNerd" Evans wrote:
> On Wed, 13 Dec 2017 15:36:06 +0200
> Sawyer X <> wrote:
>>> So if at some point in the future I make a change to the internals
>>> of the context stack implementation which breaks your module, who
>>> is is responsible for fixing it?  
>> That's easy: It's Paul.
>> However, there are two situations this doesn't solve:
>> * If Paul is unavailable, the users are doomed, unless someone adopts
>> it (or co-maintains).
>> * If Paul is unwilling, the users are forced to contact p5p and ask we
>> fix it.
> I'm sure the same is true for any of my CPAN modules, or indeed
> equivalent for anyone else's for that matter. If core changes something
> that any CPAN module makes use of, it always comes down to trying to
> decide what's best to do about that.
> The only real difference with something like Future::AsyncAwait is the
> degree to which it digs into internals of perl's implementation. I
> happily accept that to implement what I've done I've had to read
> through many (undocumented) .h and .c files that came with perl core
> source.
> It's true that p5p provide no guarantee on changing details in there,
> however I don't think it fundamentally changes the nature of support of
> my module. I have many other modules whose correct behaviour depends on
> external factors - Amazon webservices, Google, many external C
> libraries. These are all liabilities to future breakage - p5p is not
> unique among them.


>> While it is clearly Paul's responsibility, I sympathize the general
>> concept Dave is raising here: The end result is that everyone (both
>> the users and p5p as an extension of the 2nd clause) depends on Paul
>> being available and willing to continue updating. We had to deal with
>> this in the past and still do. I won't mention examples because we
>> all know them and the incredible frustration involved.
>> While Paul is a far more cooperative person than others, the first
>> clause still applies. "Unavailable" could also mean "not (currently?)
>> capable." The next internal change might be much harder to deal with
>> or might not be possible even. It's a lot of responsibility to take
>> on.
> I thank you for your kind words Sawyer :)
> Yes I'll happily accept there might be an occasion when I'm not
> available to fix whatever needs fixing, but again want to point out
> that really the situation is the same for any other module.

One of the points I was subtly trying to imply is that I think that in
some cases it might be an unfair burden to put on you or other module

If your code needs more than what the language has to you without having
to bend over backward to make it work (and to provide compatibility when
it inevitably breaks), we should revisit it. One option is to give up
and say "We can't provide this cleanly. Implement it however you want at
your peril." We can say this, but it feels like the last resort, merely
admitting we can't or uninterested in offering what you need. Another
option is to add the APIs you need cleanly. The problem with this is
that we might corner ourselves having to maintain support for something
that might be in the way of something in the future. The third option is
also raised here, which is to core some of it - or perhaps all of it.

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