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

Re: review of perlexperiment, 2021-10

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
October 5, 2021 11:50
Subject:
Re: review of perlexperiment, 2021-10
Message ID:
YVw79+fky/CqOTXU@etla.org
On Sun, Oct 03, 2021 at 04:41:37PM -0400, Ricardo Signes wrote:

> *pluggable keyword API* — Calling this experimental is also weird.  We have had a number of PSC (and other) conversations about changing how pluggable keywords work so that their implementation could be less exposed, and certain hooks could be made experimental so they'd warn when being hooked into.  *I would love to see an email about this from Nicholas or Paul.*  #13199 <https://github.com/Perl/perl5/issues/13199>

I really don't have an opinion about removing hooks (in general), or this one
in particular. (I note that Paul has mailed specifics about this one.)

The thoughts I had were more that we shouldn't add new hooks as we had been
- a pointer in a data structure that your code manipulates to "register"
its callback, and de-facto scribbles over the previous value/does something
with it/who knows.

Instead we should have an API - one API call that your uses to register its
callback, and a second to de-register the callback.

(And I think two API calls total, not two per callback type.
Have "what are you hooking into" be an enumeration)

This way we can have the "register" API generate warnings at load time if
the feature is deprecated, which are visible to the *user* of the module,
in Perl space.

Instead of what we have now which is we try to make the C compiler generate
deprecation warnings, which are visible to the OS package builder automated
toolchain, which couldn't give two hoots about it, and they fall on the
floor.

But I don't think that this fits into this thread.

Nicholas Clark

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