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:50
Subject:
Re: Indented here docs?
Message ID:
577B82EC.10406@gmail.com
On 07/05/2016 11:45 AM, Sawyer X wrote:
> 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.
I still left it somewhat unclear. I apologize. Ilmari was quick to
clarify me, so I'm adding this as well:
<ilmari> sawyer: by "deprecation", I think you mean feature removal
<sawyer> ilmari: Yes.
<ilmari> bare << to mean <<"" is already deprecated, we're talking about
forbidding it outright
<sawyer> ilmari: Yes.
Thank you, sir. :)
Thread Previous
|
Thread Next