Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
July 5, 2016 09:45
Subject:
Re: Indented here docs?
Message ID:
577B819C.5040901@gmail.com
On 07/05/2016 02:35 AM, Rocco Caputo wrote:
>> On Jul 4, 2016, at 17:25, Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> On 07/03/2016 10:31 PM, Dagfinn Ilmari Mannsåker wrote:
>>> Father Chrysostomos <sprout@cpan.org> writes:
>>>
>>>> Paul Johnson wrote:
>>>>> On Sun, Jul 03, 2016 at 03:28:56PM -0400, Matthew Horsfall (alh) wrote:
>>>>>
>>>>>> Aside from the above, do we have a decision/consensus on if we need a
>>>>>> deprecation cycle for the existing behaviour of <<-EOF / <<-"EOF" etc?
>>>>>> (which, as far as I can tell, is to throw a warning and then
>>>>>> eventually fail compilation? Or are there some cases where this is
>>>>>> legal somehow?
>>>>>>
>>>>>> Also, is this going experimental for 5.26?
>>>>> I suppose that one option is to have a deprecation cycle in 5.26, and
>>>>> also add this as experimental option which would silence those
>>>>> deprecation messages. Then we might want to relax our rules about two
>>>>> stable releases and remove the experimental status in 5.28.
>>>> The existing behaviour of <<- is already deprecated. I think we can
>>>> go ahead and change it.
>>> Just a data point: it's been deprecated since 5.002, i.e. for over 20
>>> years. As far as I can tell it's the second-oldest deprecation still in
>>> place in toke.c, after comma-less variable lists in formats, which was
>>> deprecated in 5.000.
>> This point is very convincing. I'm not against adding this as 5.26
>> experimental while deprecating fully <<-, as Paul suggests.
>>
>> If all goes well, and we don't experience problems[1], I'm in favor of
>> considering relaxing the rules for this specific one for 5.28. No
>> promises, though.
>>
>> Sounds reasonable?
>> Does anyone object?
> I object. People who aren't following P5P will see this as an ad hoc exception made at a risk to users because Perl's developers wanted the feature sooner. Anyone bitten by the change will not recognize the global risk as being small. It sets a bad precedent for inconsistent development behavior. It undermines P5P's and Perl's reliability.
>
> All my objections go away if this new rule is codified before it's followed: Anything deprecated 20 years or more can be removed or altered without further notice. It still sets a precedent, but the scope is much narrower. It's not as capricious.
>
> For maximum fairness, policy changes should be published before they're followed, but the skin in the game I'm trying to protect is y'all's, not my own.
Let me try and clear it up what I meant.
I'm not suggesting breaking rules. We have removed features that had
been long-time deprecated. This is not new. We are also not suggesting
adding this new feature without a two-step experimental phase. That is
also the rule and we're not changing this. So far I do not see any
"exception" or "ad hoc exception".
The question I am raising here is whether we can both drop a feature
deprecated since 5.2 *and* introduce a new experimental phase feature in
one release, instead of two releases. I don't see any policy entry
regarding this situation.
The syntax will not be automatically re-purposed anyway, because we're
following the policy, stating at least two releases in experimental
phase. If we do this, it means that - unless you enable a new
experimental feature on purpose - we just dropped something that has
been deprecated since 5.2[1]. If you choose to enable a new experimental
feature, you're purposefully asking for this syntax to mean a new thing.
It will stay experimental in this and the next release anyway, following
the policy.
I don't see as big of a problem as it might seem.
Also, please take into account that, as rjbs noted:
[...] pair slices (%hash{ a, b, c}) were added
without an experimental phase in the same release that added
other features *in* an experimental state. This was intentional.
Which means that introducing *without* an experimental phase has had
intentional exceptions. But that's not what I'm suggesting here either.
[1] 1996-Feb-29, according to perlhist.
Thread Previous
|
Thread Next