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
Leon Timmermans
December 17, 2017 22:41
Re: Request For Context - about the 5.22->5.24 context stack rework
Message ID:
On Sun, Dec 17, 2017 at 3:55 PM, Sawyer X <> wrote:

> >> 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
> authors.
> 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.

I think in this phase Paul's approach is the right one. Formalizing such
APIs is a good idea, but it having seem some real usage to proof that
they're the right APIs is valuable. If it all works out well (which I
suspect it will) then embedding the APIs in core is a logical follow-up
after a while.


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