develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC 0004 - defer {} syntax

Thread Previous | Thread Next
From:
hv
Date:
June 16, 2021 23:20
Subject:
Re: RFC 0004 - defer {} syntax
Message ID:
202106162247.15GMlRP28940@crypt.org
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
:Here's an RFC formalization of my currently-open github feature issue:
:
:  https://github.com/Perl/perl5/issues/17949
:
:which was itself an issue tracking the previous mailing list
:conversation:
:
:  https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257611.html
[...]

:As well as being more convenient for users, it would help decouple Perl
:core's object behaviours, like `DESTROY`, from this task. If less code
:relies on DESTROY, it may one day be possible to change the way that
:part of the code works, without worrying so much about code that relies
:on it breaking.

At least the second sentence here feels like a red herring. I'd be very
happy to see defer in the language, but I cannot envisage its existence
significantly reducing the need to retain DESTROY behaviour within any
relevant timescale.

:Another rejected idea is that of conditional enqueue:
:
:  defer if (EXPR) { BLOCK }

Given the (snipped) reference to symmetry with the behaviour of local,
I would be hopeful that you could get the same effect with:
  defer BLOCK if EXPR;
just as we can get conditional localization (something of which I make
heavy use in recursive code), eg:
  local @hash{@keys} = @values if $localize;

Hugo

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About