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

Re: RFC 0004 - defer {} syntax

Thread Previous | Thread Next
Nicholas Clark
July 2, 2021 09:20
Re: RFC 0004 - defer {} syntax
Message ID:
On Wed, Jun 16, 2021 at 11:15:40PM +0100, Paul "LeoNerd" Evans wrote:

> ## Motivation

> It would be nice to offer a native core syntax for this common
> behaviour. 

: ((TODO - I admit I'm not very clear on how to split my wording between
: the Motivation section, and this one))

It seems much easier in theory that in practice. I *think* that it goes
roughly here (splitting your paragraph). Above this point is "problem I want
to solve" and below here is "my proposed solution".

Except that the next sentence flows nicely as part of the reasoning of *why*
so having the next line read "A simple explicit syntax for this" instead
would make a cleaner separation.

>            A simple `defer { BLOCK }` syntax removes from the user any
> requirement to think about storing the guard object in a lexical
> variable, or worry about making sure it really does get released at the
> right time.

I don't think it really matters if you change the wording you had. But
take the TODO out - on balance I think you got it about as right as is
possible, but I still think that it's important to attempt to separate

    Motivation - The existing problem
    Rationale  - My solution, and why it is good

even if those aren't the best names for the two.

> 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.

IIRC after discussion you took this out, but I think that a variant of it
does belong here. Something like:

    As well as being more convenient for experienced programmers, it would
    make it easier to explain the code to newcomers. as it makes the desired
    behaviour explicit, rather than behaviour emergent from deliberate
    combination of side effects of core's object behaviours.
    (ie what `DESTROY` is, and the timing of implicit object destruction)

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About