Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
From: Aristotle Pagaltzis
July 11, 2016 02:35
Re: Indented here docs?
Message ID: 20160711023538.GA56531@plasmasturm.org
* Zefram <email@example.com> [2016-07-11 03:48]:
> Aristotle Pagaltzis wrote:
> > *If* we want to do something similar again. But we have no such
> > plans at this time.
> If we wait until we've actually run out of non-clashing syntax, that
> would be a much worse impediment. It might lead us to cut corners,
> such as by reassigning legal syntax to a new meaning within a single
> major version.
So the reason we should break backcompat now is to avoid being tempted
to cut corners on it later? How about we just not cut corners?
> > That is the exact opposite of the current dictum to not break
> > backcompat until and unless it impedes actual changes.
> It did impede this change: we did not have a free choice of reasonable
> syntactic options. We've used just about the only one available.
> Given the precedents in other languages for "<<-", there was a good
> case for using that, but we can't.
Why can’t we? We can remove bare << (or a specific case of bare <<) and
then use the room that opens up to introduce <<-.
If we can’t remove bare << in order to make room for <<-, why can we
remove it in order to make room for a thought-experiment hypothetical?
We are not forced to choose <<~. We are only forced to choose it if we
want to preserve bare <<.
But to say that we are forced to choose <<~ and must also remove bare <<
> > Since long-standing deprecations are bad for
> >the language, it should be done away with.
> You can't have it both ways.
Nor did I ask to have it two ways.
> A policy requiring some degree of active impediment to new development
> for removal inherently means that deprecations will tend to last
> a long time.
No. It means discouragements may last a long time, and it’s fine if they
do. It has no effect on how long deprecations need to last, and it’s bad
if that is long. This distinction was the whole point of my argument but
completely elided in your citation.
> If you want to avoid long-duration deprecations, by all means agitate
> for a change to the rule, to allow (or require) deprecated features to
> be removed two major versions after deprecation, even if they're not
> yet actually causing trouble.
The rules already say backcompat should only be broken when concrete
necessity arises, and they already distinguish between discouragements
and deprecations. I don’t need to agitate for anything.
> I think your argument suffers from failing to distinguish between
> classes of clash between deprecation and new development.
You conflated deprecation and discouragement, and under those conditions
I guess my argument would have that problem. But that is not a problem
with my actual argument.
> There are some cases, such as $[, where support for a deprecated
> feature implies some internals that are troublesome, and so impede
> later features that don't necessarily have any user-obvious link. In
> those cases we can delete a deprecated feature and reap the benefit of
> doing so in the same version. So in those cases it is reasonable to
> look for such imminent benefits as the precondition for removal, as
> you advocate.
> Deprecating the use of some syntactic space, clashing with proposed
> reuses of that syntactic space, has a different character. In this kind
> of case, removing the deprecated use and then reusing the syntax in the
> same version would cause an obvious compatibility problem.
> To avoid silently changing the meaning of any program, we'd really
> like to perform a more staged transition, with the syntax lying fallow
> for a couple of major versions. We don't always do that -- it's
> a tradeoff -- but we'd certainly like to do it. If we wait for
> a specific reuse to be decided upon, then the full process would take
> three years to introduce the new feature. Given the downsides of that,
> it's reasonable to apply a weaker standard for clashes to trigger
> removal: a semi-specific anticipation of syntax reuse, or as in the
> present case an averted clash demonstrating that the syntax would be
> profitable to reuse.
Maybe you should agitate for a rule change. :-)
> I interpret our policy on removing deprecated features to allow this
> kind of nuanced decision about the required justification. The policy
> is not a set of absolutely strict criteria; reasonableness in applying
> the policy is required throughout.
Well, so do I. I don’t think the full cycle is absolutely warranted in
this case, at the very least depending on the particulars of the choice
Aristotle Pagaltzis // <http://plasmasturm.org/>