Front page | perl.perl5.porters |
Postings from February 2021
On Thu, Feb 04, 2021 at 12:22:48PM +0000, Paul "LeoNerd" Evans wrote: > Oh indeed there is; but the same tension is always present for any > other feature too. It might vary to different degrees in different > situations, but whenever adding any feature you always have to consider > the long-term support implications behind whatever you document as > being "the thing". > > I often find the way to approach that is to start off trying to *use* > the newly added feature, imagining it to be added in whatever form I > would find most convenient to use. That way I have some test cases, and > a feel for "what would users want to use?" that are made independently > of how it might be implemented. Hopefully a sufficiently-practical and > useful interface is not so tightly constrained to its implementation > that it unduely constrains the shape of that implementation. 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. In general a hook exposes a new part of the perl internals that was previously allowed to be modified by ourselves any way we want, but now has to maintain the current behaviour to avoid breaking any XS code which hooks into it. To give an example (one of many): perl's peephole optimiser is hookable; both for the top-level call which "peepholes" an entire optree, but also at the recursion level: you can hook each time Perl_rpeep() is called to follow along an alternative execution path as found in LOGOPs etc. It's documented - people are told it's there and they can use it, but its not documented in terms of what perl promises as regards how and when it will recurse. So people will write XS modules using it based on "what perl does at the moment". So if perl's behaviour changes, the behaviour of the XS code may change. At a trivial level, suppose I want to fix the peephole optimiser in some way to avoid deeply recursing (and so avoid crashing the stack on deeply nested and perhaps auto-generated code like A ? B : C ? D : E ....). Now the fix is harder because I may be changing where and how often the rpeep hook is called and thus triggering lots of BBC reports for CPAN modules I've now broken. Or more generally, if in the future I want do to Brave New World stuff to do with perl compiling - e.g. separate out op chains into Basic Blocks for better optimisation, or translate to LLVM or bytecode or whatever - its an albatross around my neck. 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 :-) -- In economics, the exam questions are the same every year. They just change the answers.Thread Previous | Thread Next