Front page | perl.perl5.porters |
Postings from April 2016
Re: [perl #127875] Blead breaks Scope::Upper
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
April 12, 2016 23:45
Subject:
Re: [perl #127875] Blead breaks Scope::Upper
Message ID:
20160412234512.GA12450@debian
* Tony Cook via RT <perlbug-followup@perl.org> [2016-04-11T20:09:39]
> a) Scope::Upper should be maintained in core, since it's tied so much to the
> implementation, or
Doing this doesn't produce the labor to keep it maintained. Instead, it acts
to create a higher barrier to changes that would break Scope::Upper.
That is: if Scope::Upper is core, then you can't break it without breaking
core, so either:
a. you change "perl.c", and then also do the work of updating Scope::Upper
b. you decide not to make the changes in the first place
This is one way of carrying out a ruling that Scope::Upper is too important to
allow to be broken. Jumping to this strategy is begging the question.
To me, the vital questions are:
**Specifically:** can Scope::Upper be fixed with the APIs now available in
v5.24.0-RC0? That is: if we release as-is, can it be fixed subsequently?
The options seem to be:
1. ship v5.24.0 with Scope::Upper broken, but with the performance
improvements and bugfixes of the context work in place
2. revert the contexts work, putting it on hold until 5.25.x when someone
(who?) has made Scope::Upper work with it
In case (1), we hope that Scope::Upper can be fixed on v5.24.0 with rework, or
that the specific shortcomings of the existing (still not-public!) API can be
determined so that it can be fixed on v5.25.x. If no one updates Scope::Upper,
it remains broken "forever." (Even if some further, public API is provided,
Scope::Upper would need to be updated to use it.)
In case (2), we must further decide whether the contexts work is permanently
blocked if no one ever overhauls Scope::Upper to work with it.
**Generally:** what is the appropriate way to divide cases where p5p is "on
the hook" and those where a module author is?
As Karl said, it's not realistic that by writing code against an "unpublished"
API, any API can become guaranteed. On the other hand, does this mean that end
user code surives only at the pleasure of the committers? Maybe, except that
the committers need to be guided by the idea that breaking downstream code has
a cost, and the cost needs to be considered beyond a mere "they shouldn't have
done that."
Still, there has to be a line drawn between what can be supported and what
cannot, and right now that line is the public API. It's not a great line. We
have talked about trying to improve it in the past, but so far nothing has
actually been done. What we've said in the past is that if you want to build
something that you can rely on, by all means build it now, but then come to p5p
and say, "Look, I made a thing. This thing is useful. I want to make sure it
doesn't get broken in the future. What can be done?" (This gets to what was
(b) in Tony's mail.)
That shares the onerousness: some for p5p to provide a public API and some for
the reporter to rework code to use it.
--
rjbs
Thread Previous
|
Thread Next