Front page | perl.perl5.porters |
Postings from February 2023
On Tue, 31 Jan 2023 at 19:20, shmem <shmem@cruft.de> wrote: > > From the keyboard of demerphq [31.01.23,10:14]: > > [...] > > I have been thinking that maybe we should do something similar for > > PERL_USE_VOLATILE_API, and maybe also with experimental apis. For > > instance we could specify a PERL_USE_VOLATILE_API key for each > > (major?) release. Anything using the API's would have to specify the > > correct key in the define for each version of perl. This would ensure > > that people understand that if they are to use the volatile API they > > will have to update their code *each* *release*. Similarly we could do > > the same with experimental features. Each release we could specify a > > string that must be provided to these features (or maybe set in the > > environment or something), so that they continue to work. > > This would make things worse towards two directions - stable, and > experimental. Yeah, I'm starting to think that the cure will be worse than the disease. > > This would ensure that people understand that if they use these > > volatile or experimental things there will be a permanent maintenance > > burden from doing so, and that they will have to deal with breakage > > every release. > > People using experimental or volatile things *already know* that > these things are *volatile or experimental*, Well, while that is true, we have gotten yelled at for changing experimental things, and people like Dave M feel handcuffed in improving parts of the internals by the fact we have exposed some of them as API's. A perfect example of Hyrums law. I think we have even gotten yelled at for de-experimentalizing things because then the use statement that allowed them no longer works. Damned if you do, damned if you don't. > they would not experiment > any benefit from the procedure, but get more reluctant to try things > due to the burden placed upon them. > > Of course this would strongly dissuade people from using experimental > > features in production, and it would impose a maint burden on XS > > authors using these volatile API's but it would free us from having to > > deal with the fallout when we actually do change these things and it > > causes gnashing of teeth because people have been fooled into thinking > > it was stable. After all, if you use something that says on the box > > "this will change every release" and it does so consistently then you > > can hardly complain when it changes in a more substantial way. > > I can't imagine how any reasonable developer would want to use things > experimental or volatile in production, except if it is a crucial change > which allows them to scratch a very old itch. We see signs of it all the time tho. > See, any good Burger King uses well seasoned loafs of meat in their > daily work because they don't want to be hit by the annoyance of a > steak jumping out their frying pan after applying a pinch of salt. > Or pepper, chili, your choice. Not sure I get the analogy here. TBH, but your vote against the idea is registered. :-) Cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next