Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^2: DESTROY and AUTOLOAD in 5.20.1 (fixed bug)

by szabgab (Priest)
on Apr 24, 2015 at 21:22 UTC ( [id://1124612] : note . print w/replies, xml ) Need Help??

in reply to Re: DESTROY and AUTOLOAD in 5.20.1 (fixed bug)
in thread DESTROY and AUTOLOAD in 5.20.1

That might be the case, but I could not find any documentation about that change and my understanding of the 5.20.1 is that it still is expected to be the old behavior.
  • Comment on Re^2: DESTROY and AUTOLOAD in 5.20.1 (fixed bug)

Replies are listed 'Best First'.
Re^3: DESTROY and AUTOLOAD in 5.20.1 (fixed bug)
by jeffa (Bishop) on Apr 24, 2015 at 21:39 UTC

    I'm a bit flabbergasted that this was not more loudly advertised. I think i like the change ... it seems awful silly to have to declare a sub that does nothing if you want default behavior. I tried searching for "destroy" from this delta page, but didn't find anything that seemed directly related:

    • Changes to UNIVERSAL::DESTROY now update DESTROY caches in all classes, instead of causing classes that have already had objects destroyed to continue using the old sub. This was a regression in Perl 5.18. (perl #114864)
    • When die, last, next, redo, goto and exit unwind the scope, it is possible for DESTROY recursively to call a subroutine or format that is currently being exited. It that case, sometimes the lexical variables inside the sub would start out having values from the outer call, instead of being undefined as they should. This has been fixed. (perl #119311)
    • Undefining a glob that triggers a DESTROY method that undefines the same glob is now safe. It used to produce "Attempt to free unreferenced glob pointer" warnings and leak memory.
    • If subroutine redefinition (eval 'sub foo{}' or newXS for XS code) triggers a DESTROY method on the sub that is being redefined, and that method assigns a subroutine to the same slot (*foo = sub {} ), $_[0] is no longer left pointing to a freed scalar. Now DESTROY is delayed until the new subroutine has been installed.

    I don't think any of these are directly responsible for the change, but perhaps they might be implicitly? Sorry i don't have an answer, but maybe this will help you track down when it happened. It should be advertised, methinks ... maybe it was in error?


    (the triplet paradiddle with high-hat)