Front page | perl.perl5.porters |
Postings from February 2021
On Mon, Feb 08, 2021 at 06:25:25PM +0000, Paul "LeoNerd" Evans wrote:
> 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"?
...
> 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.
The thing is that the real world doesn't work like that. If someone makes
a CPAN module using such hooks which becomes popular, then if the perl
core breaks that module, people will start shouting. For example when I
heavily rewrote all the context stack stuff in 2016, which (a) made scope
entering and exiting (including sub calls) a lot faster, and (b) fixed or
made fixable a whole bunch of scope-exiting edge cases (like $@), it broke
Scope::Upper, which it turned out was a basic dependency of much stuff. It
was generally agreed that perl couldn't be released with this breakage. I
ended up spending 76 hours fixing Scope::Upper, plus further time on
dealing with other fallout.
So no matter how many caveats are issued, at the end of the day if it
breaks the perl ecosystem, pragmatism tends to win out above "I told you
so". Especially as caveats tend to weaken or disappear further up the
foodchain. For example, perl's docs say "this hook's API may change/break
without notice"; Paul's module says "this module isn't guaranteed to work
on future perls"; Fred's module which becomes really popular and use's
Paul's module says nothing. When Fred's module breaks, users of Fred's
module shout quite reasonably that there was no notice against using
it.
But to the specific proposal of allowing a hookable context type. How much
I like or dislike about such a proposal would depend on the totality of
the API - not just that if you push CXt_CUSTOM, your hook will get called
on scope exit, but rather what guarantees are made (and more importantly
not made) about when the hook will and won't be called, under what events
and exceptions - for example such permutations as 'return', 'die', runtime
error, or exit() within a sort, grep or eval block. Should we guarantee
such behaviour? Should XS authors be allowed to make assumptions about
what else is on the context stack, and what manipulations they may make to
it?
A decent API design is a lot more than a hook.
--
Modern art:
"That's easy, I could have done that!"
"Ah, but you didn't!"
Thread Previous
|
Thread Next