Take a walk down history lane with me here:
https://www.perl.com/pub/2000/06/dougpatch.html/
Like ithreads, the idea was sparked from Gurusamy's genius, coded up by
Doug, and largely forgotten by p5p politics.
It's not that it couldn't be done, they arrived at the place where it
*shouldn't* be
Every method call that's implemented in XS is looked-up at compile-time in
that script, even for class methods.
That's the sweet spot for :sealed. The only other things I do with it are
a few hot methods in Dotiac::DTL::Core, but that's probably not worth the
bother.
On Tue, Aug 30, 2022 at 1:14
Just look through my commit history on this sample Registry script to see
what's involved in getting sealed activated on your scripts.
https://github.com/SunStarSys/cms/blob/master/enquiry.pl
On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
> It'd be pretty harmless to apply the
It'd be pretty harmless to apply the RegistryCooker.pm patch once we find a
home for sealed.pm (either in this project or as a stand-alone pragma on
CPAN).
Nothing will segfault without consciously using types on your lexical
object reference declarations; otherwise it's a giant noop.
On Tue, Aug
If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 will
still segfault, but there's not much more I can do with the code at this
point to prevent that.
B::Generate doesn't really support what I'm doing here, which is to do
surgery on an existing op-tree, instead of just playing
Someday this patch might be interesting:
diff -u RegistryCooker.pm~ RegistryCooker.pm
--- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
+++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
@@ -399,7 +399,8 @@
my $eval = join '',
'package ',
