Front page | perl.perl5.porters |
Postings from December 2017
On Sun, Dec 17, 2017 at 3:55 PM, Sawyer X <xsawyerx@gmail.com> 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. LeonThread Previous | Thread Next