Front page | perl.perl5.porters |
Postings from February 2021
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Thread Previous
|
Thread Next
From:
Paul "LeoNerd" Evans
Date:
February 8, 2021 18:25
Subject:
Re: Do we want PL_operator_plugin? [was: Re: Do we want aCXt_CUSTOM?]
Message ID:
20210208182525.33078909@shy.leonerd.org.uk
TL;DR summary:
I accept the breakage-guarantee point, but I want a way to iterate
new designs faster than bleadperl's yearly release cycle.
On Mon, 8 Feb 2021 16:49:26 +0000
Dave Mitchell <davem@iabyn.com> wrote:
> I hate and loathe hooks. Each individual proposal seems superficially
> reasonable, but added together they gradually make what are supposed
> to be the internal details of the perl core more and more exposed and
> ossified.
...
> Hooks give people the illusion of flexibility and being able to expand
> perl in exciting, modern, and dynamic new ways; in reality it's a
> further nail in the coffin.
>
> (This is all just my opinion of course :-)
Yes; those are all reasonable counter-arguments against the idea of
adding it. It's always a tricky two-sided question.
Perhaps I can add some more motivation.
I am quite interested in experimenting with some new equality operator
ideas I have - equ and === - which would treat undef as their own
special value; so `undef equ ""` and `undef === 0` are both false.
While I -could- do this purely within bleadperl itself, that is at
least one if not two orders of magnitude slower to iterate and
experiment on a design in real production code (i.e. beyond toy
examples in in-core unit tests).
I have been very fortunate that `PL_keyword_plugin` and the `OP_CUSTOM`
mechanisms exist, because they have allowed me to make CPAN modules to
experiment with
* try/catch [Syntax::Keyword::Try], now moved to core ;)
* FINALLY [Syntax::Keyword::Finally]
* async/await [Future::AsyncAwait]
* class/has/method [Object::Pad]
* dynamically [Syntax::Keyword::Dynamically]
* and several other ideas I have yet to publish.
In many of these cases, I am actually helping support those features
in Real Production Code, deployed for real in actual money-making
applications for clients I work for. That has been possible *only*
because those can be iterated on entirely in CPAN modules. I can deploy
code on a Monday, take feedback over the next few days, and adjust and
change the module for a second update later in the same week even.
This velocity is simply impossible for bleadperl's yearly release cycle
to manage. If I was forced to develop those features only in core, then
it is highly doubtful any of it would exist already today - certainly
nothing as nontrivial as async/await would. I merged try/catch into
bleadperl last week by basically copying what Syntax::Keyword::Try
does. Without the syntax hook that would not have been possible.
That all said, I do accept that there is a tradeoff here. Personally,
I'd be quite happy to add code for `PL_operator_plugin` into bleadperl
and not even bother documenting it or telling anyone about it, purely
so that I could develop some syntax modules myself. I could test them
out on my own systems to experiment with the ideas, as a high-velocity
testbed for getting the idea stable enough to add to core for real.
I suspect others may not be happy if I did this though ;)
Could we find a compromise position somehow? Strongly Worded
Documentation, a ./Configure-time guard, something to make such a
feature well and truely "we make no guarantees whatsoever. We will
absolve all responsibility of BBC to the point that if your module
breaks we will point and laugh"?
In -theory- perl5-porters are supposed to be able to support uses of
the existing `PL_keyword_plugin` mechanism. In -practice- who is
actually using that on CPAN right now? I know of 5 nontrivial modules
of my own, plus 2 by MAUKE (who hasn't been seen around in maybe three
years now), and a few by ZEFRAM (who is similarly AWOL). In practice, I
am not personally aware of any other CPAN author who is even using the
existing hooks, other than myself. I suspect any newly-added hooks
would follow a similar pattern.
I personally would be happy to add and use a new hook, well aware that
if in future you break anything I'm using it for, you can all point and
laugh at me.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next