Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
Thread Previous
|
Thread Next
From:
Alberto Simões
Date:
July 2, 2016 20:22
Subject:
Re: Indented here docs?
Message ID:
e67409e7-9ad7-d199-2612-71d4cbc7f159@alfarrabio.di.uminho.pt
On 02/07/16 21:03, Sawyer X wrote:
>
>
> On 07/01/2016 08:18 PM, Ricardo Signes wrote:
>> * Alberto Simões <albie@alfarrabio.di.uminho.pt> [2016-07-01T14:11:55]
>>> On 01/07/16 18:00, Matthew Horsfall (alh) wrote:
>>>> I'm fine with whichever. I modelled mine lightly after ruby 2.3.x
>>>> which added <<~ to do indented heredocs since <<- already had meaning
>>>> for them.
>>>>
>>>> Is it a simple matter of changing ~ to -, or do we have to worry about
>>>> deprecation and such as you state.
>>>>
>>>> -- Matthew Horsfall (alh)
>>> As far as I understood (moron here, too, like other commented in this
>>> thread) from rjbs words, both <<~ and <<- had meaning before this patch, and
>>> therefore, he was happy to include it without deprecation notices.
>> [...]
>> I have no opinion about the deprecation warning issue or scheduling. I prefer
>> <<- if it is consistent with other systems.
>
> When we speak of fully removing the syntax in its deprecated form, will
> it die instead of warning, or will it entirely not be parsed properly
> anymore?
>
> I've written the following in case we're discussing a die instead of
> warning. If we're discussing removing it entirely from the syntax
> ("Sorry, I don't understand what this means"), I don't think the
> following text applies, and off-hand I see no problem with the suggested
> change.
>
> The benefit of a full deprecation cycle is that one version could simply
> remove it entirely and say "Nope, doesn't exist anymore" and the next
> can provide a new functionality knowing the previous version removed the
> syntax prior. This means that if we both remove it and add new
> functionality with the syntax in the same version (say, 5.26), there is
> no chance for a user to remove the syntax in its deprecated usage. In
> other words, if a user moves to 5.26 and the syntax is gone and replaced
> with a new feature, she no longer has a chance to change <<-Foo to
> <<"-"FOO because she will not get an error that it isn't supported anymore.
>
> A counter-point is that there is a significant amount of users who jump
> versions. Many distributions do the same when it comes to stable (long
> time support) distribution versions. That means that it is also possible
> for users to skip 5.26 and go from 5.24 (or prior) to 5.28 (or above)
> and thus missing their chance of seeing the "Sorry, you can't use this
> feature anymore" error.
>
> I don't have an opinion on which direction to go on this yet, but I'm
> likely to err on the side of a full deprecation first (feature gone,
> you're out of luck) and introduction of new feature on top of
> now-officially released syntax in the next version. But this might not
> be a very important case for a full deprecation cycle.
>
> Thoughts?
Someone (sorry, can't recall who) did a grep on CPAN and found mostly no
usage of that idiom. If we can have mostly sure that the idiom was too
obscure, and nobody used it, then I do not see a deprecation to be needed.
In any case, in case we desire the deprecation, can we add it as a
feature? As it will be active only if the user asks for it?
(just brainstorming, no idea of the inner details and if that is even
possible)
Cheers
Thread Previous
|
Thread Next