Front page | perl.perl5.porters |
Postings from December 2017
On 12/13/2017 12:06 PM, Dave Mitchell wrote: > On Tue, Dec 12, 2017 at 04:04:02PM +0000, Paul "LeoNerd" Evans wrote: >> On Tue, 12 Dec 2017 15:34:14 +0000 >>> Note that your module is making heavy use of the unpublished internal >>> details of the perl runtime engine. You might want to add a caveat to >>> the pod that this this module might irretrievably break in some >>> future release of perl. >> Oh I'm aware of that. Right now my code is purely 5.24 because that's >> what was on my laptop at the time, and I note that it happens also to >> work for 5.26. >> >> I'm hoping though that any new perl releases will have corresponding >> version-guarded support in my module, so things ought to work smoothly. > 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. 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. > [...] > What happens if common modules have come to rely upon your module? > Am I then forced to undo my change to blead, because I have "broken CPAN"? What bothers me is not the change we make. If it's unreasonable, we revert it. If it's reasonable (and covered), we shouldn't. But when the author of a module that needs updating doesn't feel like fixing it, they can (and some have) simply directed their users at p5p. "They broke my code by changing internals that were never documented or provided as public. Go tell them to change it." (This should be a warning to all users of whether you want to use modules that have an author who is unwilling to update it when they use something undocumented or non-public, but that's for another day.) > Which is why I feel users of your module should be warned that it could > break in the future without notice. I wish we could also provide a clear statement of modules that use internals and that *we* expect they might break in the future. "No liability" kind of sticker, but that's just asking to argue. >> Perhaps one day I'll even come up with a set of APIs/suggestions that >> perl core could do to make this sort of thing nicer ;) > Exposing more of the internal mechanics of the perl runtime engine via an > API just makes it even harder to change or fix the engine in future. The question to ask is, What is Paul trying to achieve? Is it reasonable? If so, how can we allow him to accomplish this in a way that we could continue to support it. Another question to ask is, should this part of core instead?Thread Previous | Thread Next