Front page | perl.perl5.porters |
Postings from February 2022
Future::AsyncAwait's XS implementation has to make copies of the currently-running CV, because it needs to store a modified version of it with some changes to the pad variables. Older versions of Future/AsyncAwait.xs used to use core perl's `cv_clone()` to do this, but for various subtle reasons this wasn't always correct. So now, it contains a near-copy of core's cv_clone() with some slight adjustments. I basically copy-pasted it and edited it until it worked. Object::Pad's XS implementation has to make copies of the CVs in roles when it embeds them into actual consuming classes, because it has to make modifications to the pad variables. Older versions of Object/Pad.xs used to use core perl's `cv_clone()` to do this, but... Guess what? In a shockingly similar story: That won't work. So once again, I have to make another near-identical copy and change it with some slight adjustments until it works again. Turns out both of my copies are slightly different to core's cv_clone, and to each other, but between them they share far more in common than these minor variations. As a longterm maintenance concern, I am a little worried about this situation. It means my copies have to keep themselves up to date with all the various minor internal changes to core perl going forward. I am half-tempted to suggest that we add a new core API function defined something like CV *cv_copy_flags(const CV *orig, U32 flags); and define some flags that adjust its behaviour in various ways, so that core's own `cv_clone()` can really just be a call to this function with a set of flags, and my other usecases can be other calls to it with different flags. What do people think here? -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Next