Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
July 4, 2016 21:08
Subject:
Re: Indented here docs?
Message ID:
577AD046.5040107@gmail.com
On 07/02/2016 10:22 PM, Alberto Simões wrote:
>
>
> 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?
I'm not sure I understand this question. Can you please elaborate?
Thread Previous
|
Thread Next