Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
From: Sawyer X
July 2, 2016 20:04
Re: Indented here docs?
Message ID: 57781E2D.email@example.com
On 07/01/2016 08:18 PM, Ricardo Signes wrote:
> * Alberto Simões <firstname.lastname@example.org> [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
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
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.