Skip Menu |
 
Report information
Id: 118511
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: eda [at] waniasset.com
Cc:
AdminCc:

Operating System: Linux
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.16.3
Fixed In: (no value)



Subject: Use of bare << to mean <<"" is deprecated - make a hard error
Date: Mon, 17 Jun 2013 11:14:29 +0000
To: "'perlbug [...] perl.org'" <perlbug [...] perl.org>
From: Ed Avis <eda [...] waniasset.com>
Download (untitled) / with headers
text/plain 4.8k
This is a bug report for perl from eda@waniasset.com, generated with the help of perlbug 1.39 running under perl 5.16.3. ----------------------------------------------------------------- [Please describe your issue here] For a long time Perl has issued a warning Use of bare << to mean <<"" is deprecated This has been deprecated for a very long time and it could now be made a syntax error. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.16.3: Configured by Red Hat, Inc. at Fri May 3 12:10:03 UTC 2013. Summary of my perl5 (revision 5 version 16 subversion 3) configuration: Platform: osname=linux, osvers=2.6.32-358.2.1.el6.x86_64, archname=x86_64-linux-thread-multi uname='linux buildvm-24.phx2.fedoraproject.org 2.6.32-358.2.1.el6.x86_64 #1 smp wed feb 20 12:17:37 est 2013 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -Dlddlflags=-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z,relro -DDEBUGGING=-g -Dversion=5.16.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.7.2 20121109 (Red Hat 4.7.2-8)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -fstack-protector' libpth=/usr/local/lib64 /lib64 /usr/lib64 libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.16' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z,relro ' Locally applied patches: --- @INC for perl 5.16.3: /home/eda/lib/perl5/ /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . --- Environment for perl 5.16.3: HOME=/home/eda LANG=en_GB.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/eda/bin:/home/eda/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/sbin:/usr/sbin PERL5LIB=/home/eda/lib/perl5/ PERL_BADLANG (unset) SHELL=/bin/bash Show quoted text
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
______________________________________________________________________
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 700b
On Mon Jun 17 04:15:00 2013, eda@waniasset.com wrote: Show quoted text
> This is a bug report for perl from eda@waniasset.com, > generated with the help of perlbug 1.39 running under perl 5.16.3. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > For a long time Perl has issued a warning > > Use of bare << to mean <<"" is deprecated > > This has been deprecated for a very long time and it could now > be made a syntax error.
I would like to see that *un*deprecated. I see no reason why that syntax should cause any problems. It doesn’t make anything less ambiguous to remove it. (On top of that, it looks nice!) -- Father Chrysostomos
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Tue, 25 Jun 2013 20:12:06 -0500
To: perlbug-followup [...] perl.org
From: David Nicol <davidnicol [...] gmail.com>
Download (untitled) / with headers
text/plain 374b


On Mon, Jun 17, 2013 at 8:33 AM, Father Chrysostomos Show quoted text
I would like to see that *un*deprecated.  I see no reason why that
syntax should cause any problems.  It doesn’t make anything less
ambiguous to remove it.  (On top of that, it looks nice!)

Me too! And while we're on the subject, it should allow space between the angle
brackets and the bareword terminator.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 654b
On Tue Jun 25 18:12:46 2013, davidnicol@gmail.com wrote: Show quoted text
> On Mon, Jun 17, 2013 at 8:33 AM, Father Chrysostomos
> > > > I would like to see that *un*deprecated. I see no reason why that > > syntax should cause any problems. It doesn’t make anything less > > ambiguous to remove it. (On top of that, it looks nice!) > >
> > Me too! And while we're on the subject, it should allow space between the > angle > brackets and the bareword terminator.
That would break << cmp <<, which currently works: $ perl -Xle 'print << cmp <<; ' -ea -e '' -eb -e '' -e '' -1 $ perl -Xle 'print << cmp <<; ' -eb -e '' -ea -e '' -e '' 1 -- Father Chrysostomos
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Wed, 26 Jun 2013 12:44:57 +0200
To: reneeb via RT <perlbug-followup [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 895b
On 17 June 2013 15:33, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Mon Jun 17 04:15:00 2013, eda@waniasset.com wrote:
>> This is a bug report for perl from eda@waniasset.com, >> generated with the help of perlbug 1.39 running under perl 5.16.3. >> >> >> ----------------------------------------------------------------- >> [Please describe your issue here] >> >> For a long time Perl has issued a warning >> >> Use of bare << to mean <<"" is deprecated >> >> This has been deprecated for a very long time and it could now >> be made a syntax error.
> > I would like to see that *un*deprecated. I see no reason why that > syntax should cause any problems. It doesn’t make anything less > ambiguous to remove it. (On top of that, it looks nice!)
FWIW I vote against this proposal. It should be an error. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: reneeb via RT <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Wed, 26 Jun 2013 19:03:36 +0200
To: demerphq <demerphq [...] gmail.com>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 932b
On 06/26/2013 12:44 PM, demerphq wrote: Show quoted text
> On 17 June 2013 15:33, Father Chrysostomos via RT > <perlbug-followup@perl.org> wrote:
>> On Mon Jun 17 04:15:00 2013, eda@waniasset.com wrote:
>>> This is a bug report for perl from eda@waniasset.com, >>> generated with the help of perlbug 1.39 running under perl 5.16.3. >>> ----------------------------------------------------------------- >>> [Please describe your issue here] >>> >>> For a long time Perl has issued a warning >>> >>> Use of bare << to mean <<"" is deprecated >>> >>> This has been deprecated for a very long time and it could now >>> be made a syntax error.
>> >> I would like to see that *un*deprecated. I see no reason why that >> syntax should cause any problems. It doesn’t make anything less >> ambiguous to remove it. (On top of that, it looks nice!)
> > FWIW I vote against this proposal. It should be an error.
I'm with Yves. Also FWIW. --Steffen
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Wed, 26 Jun 2013 19:17:05 +0200
To: Perl5 Porteros <perl5-porters [...] perl.org>
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
On Jun 26, 2013, at 7:03 PM, Steffen Mueller <smueller@cpan.org> wrote: Show quoted text
> On 06/26/2013 12:44 PM, demerphq wrote:
>> On 17 June 2013 15:33, Father Chrysostomos via RT >> <perlbug-followup@perl.org> wrote:
>>> On Mon Jun 17 04:15:00 2013, eda@waniasset.com wrote:
>>>> This is a bug report for perl from eda@waniasset.com, >>>> generated with the help of perlbug 1.39 running under perl 5.16.3. >>>> ----------------------------------------------------------------- >>>> [Please describe your issue here] >>>> >>>> For a long time Perl has issued a warning >>>> >>>> Use of bare << to mean <<"" is deprecated >>>> >>>> This has been deprecated for a very long time and it could now >>>> be made a syntax error.
>>> >>> I would like to see that *un*deprecated. I see no reason why that >>> syntax should cause any problems. It doesn’t make anything less >>> ambiguous to remove it. (On top of that, it looks nice!)
>> >> FWIW I vote against this proposal. It should be an error.
> > I'm with Yves. Also FWIW.
Oddly enough, I'm with Yves on this one too :-) Liz
CC: perl5-porters [...] perl.org
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Wed, 26 Jun 2013 19:31:47 -0400
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 869b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-06-17T09:33:08] Show quoted text
> I would like to see that *un*deprecated. I see no reason why that > syntax should cause any problems. It doesn’t make anything less > ambiguous to remove it. (On top of that, it looks nice!)
I slept on this for a few nights, because you may well be correct that it introduces no syntactical ambiguity, and because I do generally believe that 𝑑𝑒 𝑔𝑢𝑠𝑡𝑖𝑏𝑢𝑠 𝑛𝑜𝑛 𝑒𝑠𝑡 𝑑𝑖𝑠𝑝𝑢𝑡𝑎𝑛𝑑𝑢𝑚... but no. I think it's just the sort of facepalmingly "straightforward" syntax that has no real value but to further confuse the uninitiated. Thirty-two thousand eight hundred and nine shibboleths are enough. We can do without restoring one more. -- rjbs (is your astral plane broken? "de gustibus non est disputandum")
Download signature.asc
application/pgp-signature 490b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
On Wed Jun 26 16:32:27 2013, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-06- > 17T09:33:08]
> > I would like to see that *un*deprecated. I see no reason why that > > syntax should cause any problems. It doesn’t make anything less > > ambiguous to remove it. (On top of that, it looks nice!)
> > I slept on this for a few nights, because you may well be correct that > it > introduces no syntactical ambiguity, and because I do generally > believe that 𝑑𝑒 > 𝑔𝑢𝑠𝑡𝑖𝑏𝑢𝑠 𝑛𝑜𝑛 𝑒𝑠𝑡 𝑑𝑖𝑠𝑝𝑢𝑡𝑎𝑛𝑑𝑢𝑚... but no. I
think it's just the sort of Show quoted text
> facepalmingly "straightforward" syntax that has no real value but to > further > confuse the uninitiated. Thirty-two thousand eight hundred and nine > shibboleths are enough. We can do without restoring one more.
Can we at least leave it in (but deprecated) until it gets in the way of a bug fix or new feature? Removing it *will* break working scripts. -- Father Chrysostomos
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 05:35:38 +0000
To: "'perlbug-followup [...] perl.org'" <perlbug-followup [...] perl.org>
From: Ed Avis <eda [...] waniasset.com>
Download (untitled) / with headers
text/plain 493b
If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything? Show quoted text
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
______________________________________________________________________
CC: "'perlbug-followup [...] perl.org'" <perlbug-followup [...] perl.org>
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 17:12:34 +1000
To: Ed Avis <eda [...] waniasset.com>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 966b
On Thu, Jun 27, 2013 at 05:35:38AM +0000, Ed Avis wrote: Show quoted text
> If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything?
I think what FC is pointing out is: IFF a feature was deprecated because if was broken OR because it needed to free up syntax for something infinitely more consistent and/or useful - then removal after an announced deprecation is fair game. However there is no ground for removal of a deprecated feature, which already issues warnings to such effect (i.e. newbies will not use such features mistakenly). By removing stuff solely to "honor a promise" is creating work for darkpan users with the sole benefit of pleasing someone aesthetically. A quote of the irc.perl.org#dbic-cabal topic seems relevant: Show quoted text
> deprecated modules get deleted when they cause a problem and not before
My 2c
CC: Ed Avis <eda [...] waniasset.com>, "'perlbug-followup [...] perl.org'" <perlbug-followup [...] perl.org>
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 09:40:17 +0200
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 531b
On 06/27/2013 09:12 AM, Peter Rabbitson wrote: Show quoted text
> However there is no ground for removal of a deprecated feature, which > already issues warnings to such effect (i.e. newbies will not use such > features mistakenly). By removing stuff solely to "honor a promise" is > creating work for darkpan users with the sole benefit of pleasing > someone aesthetically.
Ugh. Not true. It also means that people actually trust that we're serious about deprecations. How you value that benefit is, of course, up to you to decide. --Steffen
CC: Ed Avis <eda [...] waniasset.com>, "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 09:44:02 +0200
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.7k
On 27 June 2013 09:12, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: Show quoted text
> On Thu, Jun 27, 2013 at 05:35:38AM +0000, Ed Avis wrote:
>> If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything?
> > I think what FC is pointing out is: > > IFF a feature was deprecated because if was broken OR because it needed > to free up syntax for something infinitely more consistent and/or useful - > then removal after an announced deprecation is fair game. > > However there is no ground for removal of a deprecated feature, which > already issues warnings to such effect (i.e. newbies will not use such > features mistakenly). By removing stuff solely to "honor a promise" is > creating work for darkpan users with the sole benefit of pleasing > someone aesthetically. > > A quote of the irc.perl.org#dbic-cabal topic seems relevant: >
>> deprecated modules get deleted when they cause a problem and not before
> > My 2c
I think you are confusing "discouraged" and "deprecated". If a feature is something that should not be used in production code but is allowed then its use should be discouraged in the documentation, and not marked as deprecated run time warning. If we use the term "deprecated" to mean "discouraged" then the word "deprecated" and the warnings it generate are meaningless and will be ignored, and then there is no point in having them. Once a feature is marked as deprecated we should rigorously follow through, otherwise there is no point in having the warning at all. We could manage all of this in the documentation. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: Ed Avis <eda [...] waniasset.com>, perl5-porters [...] perl.org
Subject: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 17:56:36 +1000
To: demerphq <demerphq [...] gmail.com>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 2.5k
I am taking this thread out of the RT queue. On Thu, Jun 27, 2013 at 09:44:02AM +0200, demerphq wrote: Show quoted text
> On 27 June 2013 09:12, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
> > On Thu, Jun 27, 2013 at 05:35:38AM +0000, Ed Avis wrote:
> >> If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything?
> > > > I think what FC is pointing out is: > > > > IFF a feature was deprecated because if was broken OR because it needed > > to free up syntax for something infinitely more consistent and/or useful - > > then removal after an announced deprecation is fair game. > > > > However there is no ground for removal of a deprecated feature, which > > already issues warnings to such effect (i.e. newbies will not use such > > features mistakenly). By removing stuff solely to "honor a promise" is > > creating work for darkpan users with the sole benefit of pleasing > > someone aesthetically. > > > > A quote of the irc.perl.org#dbic-cabal topic seems relevant: > >
> >> deprecated modules get deleted when they cause a problem and not before
> > > > My 2c
> > I think you are confusing "discouraged" and "deprecated".
No I am not. Show quoted text
> If a feature is something that should not be used in production code > but is allowed then its use should be discouraged in the > documentation, and not marked as deprecated run time warning. If we > use the term "deprecated" to mean "discouraged" then the word > "deprecated" and the warnings it generate are meaningless and will be > ignored, and then there is no point in having them.
We (and I mean most of the developers I run across) use the term "deprecated" to mean "Marked as 'will disappear at any time in the future, without further warnings' - do not complain when it is gone". In other words for most of us deprecations are a way for developers to disclaim complaints about future demolition work. I never treat them as *promise* of demolition work. I suspect in your book this means I am ignoring deprecations by treating them thusly? Show quoted text
> Once a feature is marked as deprecated we should rigorously follow > through, otherwise there is no point in having the warning at all.
The warning is there so that the end user has time to run a cost benefit analysis and decide when to deal with the issue - either immediately, or when the inevitable finally comes. You have no right to make this decision for others, unless you are paying for their time. Cheers
CC: demerphq <demerphq [...] gmail.com>, Ed Avis <eda [...] waniasset.com>, perl5-porters [...] perl.org
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 09:34:01 +0100
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 3.2k
On Thu, Jun 27, 2013 at 05:56:36PM +1000, Peter Rabbitson wrote: Show quoted text
> I am taking this thread out of the RT queue. > > On Thu, Jun 27, 2013 at 09:44:02AM +0200, demerphq wrote:
Show quoted text
> > If a feature is something that should not be used in production code > > but is allowed then its use should be discouraged in the > > documentation, and not marked as deprecated run time warning. If we > > use the term "deprecated" to mean "discouraged" then the word > > "deprecated" and the warnings it generate are meaningless and will be > > ignored, and then there is no point in having them.
> > We (and I mean most of the developers I run across) use the term > "deprecated" to mean "Marked as 'will disappear at any time in the > future, without further warnings' - do not complain when it is gone". > > In other words for most of us deprecations are a way for developers to > disclaim complaints about future demolition work. I never treat them as > *promise* of demolition work. I suspect in your book this means I am > ignoring deprecations by treating them thusly? >
> > Once a feature is marked as deprecated we should rigorously follow > > through, otherwise there is no point in having the warning at all.
I don't agree with the absolute here. But I totally agree with the concern. If things are marked as deprecated but seemingly never removed, then a) The reasons for marking them as such are ambiguous, rather than clear b) People will ignore the desired intent of the warnings (to stop using this) Show quoted text
> The warning is there so that the end user has time to run a cost benefit > analysis and decide when to deal with the issue - either immediately, or > when the inevitable finally comes. You have no right to make this > decision for others, unless you are paying for their time.
I see your point, but I think that you are contradicting yourself here. Given that you already described the warnings as meaning "do not complain when it is gone", then others should not be complaining if the deprecated feature is pulled promptly. Also, given that there is no reliable timeframe on deprecation eliminations, it's not actually possible for anyone to perform a cost-benefit analysis of whether to deal with it now or "at the time of removal", because without a timeframe for the latter, it's impossible to calculate the correct discount for future work. For calculation purposes, it would actually be better to stick to a firm timescale, instead of deferring as long as possible. I know *why* things are deprecated, because (one of) 1) we think that they are going to get in the way of a net more useful thing 2) with hindsight, they shouldn't be part of the design (they add more in complexity than they deliver in benefits) 3) they are becoming impossible to maintain But the trade off is getting the balance right to make the end user pain of fixing less than the end user pain of not fixing, so that we keep (most) of the end users. I don't have an answer here, but I'm not convinced that the end-member positions are correct. I'm wondering if the least worst answer is that we have a policy of removing things "not later than" a "long but bounded" time in the future. eg *) we may remove it two major releases after it is first deprecated *) we will remove it five major releases after it is first deprecated Nicholas Clark
CC: demerphq <demerphq [...] gmail.com>, Ed Avis <eda [...] waniasset.com>, perl5-porters [...] perl.org
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 18:54:57 +1000
To: Nicholas Clark <nick [...] ccl4.org>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 4.6k
On Thu, Jun 27, 2013 at 09:34:01AM +0100, Nicholas Clark wrote: Show quoted text
> On Thu, Jun 27, 2013 at 05:56:36PM +1000, Peter Rabbitson wrote:
> > I am taking this thread out of the RT queue. > > > > On Thu, Jun 27, 2013 at 09:44:02AM +0200, demerphq wrote:
>
> > > If a feature is something that should not be used in production code > > > but is allowed then its use should be discouraged in the > > > documentation, and not marked as deprecated run time warning. If we > > > use the term "deprecated" to mean "discouraged" then the word > > > "deprecated" and the warnings it generate are meaningless and will be > > > ignored, and then there is no point in having them.
> > > > We (and I mean most of the developers I run across) use the term > > "deprecated" to mean "Marked as 'will disappear at any time in the > > future, without further warnings' - do not complain when it is gone". > > > > In other words for most of us deprecations are a way for developers to > > disclaim complaints about future demolition work. I never treat them as > > *promise* of demolition work. I suspect in your book this means I am > > ignoring deprecations by treating them thusly? > >
> > > Once a feature is marked as deprecated we should rigorously follow > > > through, otherwise there is no point in having the warning at all.
> > I don't agree with the absolute here. But I totally agree with the concern. > If things are marked as deprecated but seemingly never removed, then > > a) The reasons for marking them as such are ambiguous, rather than clear > b) People will ignore the desired intent of the warnings (to stop using this) >
> > The warning is there so that the end user has time to run a cost benefit > > analysis and decide when to deal with the issue - either immediately, or > > when the inevitable finally comes. You have no right to make this > > decision for others, unless you are paying for their time.
> > I see your point, but I think that you are contradicting yourself here. > Given that you already described the warnings as meaning "do not complain > when it is gone", then others should not be complaining if the deprecated > feature is pulled promptly.
I dropped some context that was present in my original mail [1]. In it I said: Show quoted text
> IFF a feature was deprecated because if was broken OR because it needed > to free up syntax for something infinitely more consistent and/or useful - > then removal after an announced deprecation is fair game.
To summarize/clarify my position: An end-user has no right to complain that a deprecated feature got in the way of something and was removed. An end user could very well complain that a feature was gone without a technical reason (see below). Show quoted text
> > Also, given that there is no reliable timeframe on deprecation eliminations, > it's not actually possible for anyone to perform a cost-benefit analysis > of whether to deal with it now or "at the time of removal", because without > a timeframe for the latter, it's impossible to calculate the correct > discount for future work.
You know very well that this is not how the real world of PHBs work. The usual cost-benefit analysis is framed roughly as "Alrighty, out of this pile of technical debt, what do we have to do NOW and what can we do NOT NOW" Show quoted text
> I know *why* things are deprecated, because (one of) > > 1) we think that they are going to get in the way of a net more useful thing > 2) with hindsight, they shouldn't be part of the design > (they add more in complexity than they deliver in benefits) > 3) they are becoming impossible to maintain
These are all excellent guidelines (as long as 2 retains its bracketed disclaimer) 1) seems to be the case for the feature in question - namely <<''. It has already been deprecated as such. And its users (in this case FC) conceeded that if a saner use comes along he will let it go. With all that - what is the benefit of breaking his actual existing code now, instead of when the use case for <<'' becomes clear? Show quoted text
> But the trade off is getting the balance right to make the end user pain > of fixing less than the end user pain of not fixing, so that we keep (most) > of the end users. > > I don't have an answer here, but I'm not convinced that the end-member > positions are correct. > > I'm wondering if the least worst answer is that we have a policy of removing > things "not later than" a "long but bounded" time in the future. eg > > *) we may remove it two major releases after it is first deprecated > *) we will remove it five major releases after it is first deprecated
This would be a reasonable timeline, except I still fail to see the urge to break something without a clear technical need. Cheers [1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203778.html
CC: demerphq <demerphq [...] gmail.com>, Ed Avis <eda [...] waniasset.com>, perl5-porters [...] perl.org
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 10:56:13 +0100
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 3.3k
On Thu, Jun 27, 2013 at 06:54:57PM +1000, Peter Rabbitson wrote: Show quoted text
> On Thu, Jun 27, 2013 at 09:34:01AM +0100, Nicholas Clark wrote:
Show quoted text
> > I see your point, but I think that you are contradicting yourself here. > > Given that you already described the warnings as meaning "do not complain > > when it is gone", then others should not be complaining if the deprecated > > feature is pulled promptly.
> > I dropped some context that was present in my original mail [1]. In it I > said: >
> > IFF a feature was deprecated because if was broken OR because it needed > > to free up syntax for something infinitely more consistent and/or useful - > > then removal after an announced deprecation is fair game.
> > To summarize/clarify my position: An end-user has no right to complain > that a deprecated feature got in the way of something and was removed. > An end user could very well complain that a feature was gone without a > technical reason (see below).
Thanks.. Show quoted text
> > Also, given that there is no reliable timeframe on deprecation eliminations, > > it's not actually possible for anyone to perform a cost-benefit analysis > > of whether to deal with it now or "at the time of removal", because without > > a timeframe for the latter, it's impossible to calculate the correct > > discount for future work.
> > You know very well that this is not how the real world of PHBs work. The > usual cost-benefit analysis is framed roughly as "Alrighty, out of this > pile of technical debt, what do we have to do NOW and what can we do NOT > NOW"
Agree with how reality inevitably pans out. But I wouldn't call that a cost benefit analysis. That's more triaging, or at least two thirds of triaging - "what will die unless we intervene immediately" vs "what will still be living if not treated right now". I don't think that the timescale matters, other than "right now" versus "sufficiently far in the future that it's not in this budget" Show quoted text
> 1) seems to be the case for the feature in question - namely <<''. It > has already been deprecated as such. And its users (in this case FC) > conceeded that if a saner use comes along he will let it go. With all > that - what is the benefit of breaking his actual existing code now, > instead of when the use case for <<'' becomes clear?
Show quoted text
> This would be a reasonable timeline, except I still fail to see the urge > to break something without a clear technical need.
Yes, it is bugging me that removing things *feels* more like dogma than pragmatism. But this case, it's arguably also a language design issue, and a maintenance issue. Bother of which is harder to quantify. ie a) it's *marginally* harder to teach people a language with yet another special-case feature. (Or expect them to maintain code with it) b) it's *marginally* harder to maintain the code codebase because the code to deal with the feature exists The case of (IIRC) do subroutine syntax springs to mind. IIRC chromatic calculated that 2% (or was it 4%) of the Perl grammar exists just to deal with it. From a language-user point of view it's not getting in the way - if you don't use it, it doesn't hurt you. But it's potentially one of the "thousand cuts". So no individual change is worth it. On its own. But the sum of quite a few of them start to take things in the right direction. So I don't think it's purely dogma to be removing things before they are *actively* in the way. So there's a cost to any approach. Nicholas Clark
CC: demerphq <demerphq [...] gmail.com>, Ed Avis <eda [...] waniasset.com>, perl5-porters [...] perl.org
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 20:22:43 +1000
To: Nicholas Clark <nick [...] ccl4.org>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 4.1k
On Thu, Jun 27, 2013 at 10:56:13AM +0100, Nicholas Clark wrote: Show quoted text
> On Thu, Jun 27, 2013 at 06:54:57PM +1000, Peter Rabbitson wrote: >
> > You know very well that this is not how the real world of PHBs work. The > > usual cost-benefit analysis is framed roughly as "Alrighty, out of this > > pile of technical debt, what do we have to do NOW and what can we do NOT > > NOW"
> > Agree with how reality inevitably pans out. But I wouldn't call that a cost > benefit analysis. That's more triaging, or at least two thirds of triaging - > "what will die unless we intervene immediately" vs "what will still be > living if not treated right now". > > I don't think that the timescale matters, other than "right now" versus > "sufficiently far in the future that it's not in this budget"
This is precisely what I was trying to convey. Show quoted text
> > 1) seems to be the case for the feature in question - namely <<''. It > > has already been deprecated as such. And its users (in this case FC) > > conceeded that if a saner use comes along he will let it go. With all > > that - what is the benefit of breaking his actual existing code now, > > instead of when the use case for <<'' becomes clear?
>
> > This would be a reasonable timeline, except I still fail to see the urge > > to break something without a clear technical need.
> > Yes, it is bugging me that removing things *feels* more like dogma than > pragmatism. But this case, it's arguably also a language design issue, and a > maintenance issue. Bother of which is harder to quantify. ie
Show quoted text
> a) it's *marginally* harder to teach people a language with yet another > special-case feature.
I thought this has already been addressed... While teaching it is perfectly acceptable to gloss over anything deprecated. It is even acceptable to gloss over *discouraged* practices (e.g. 2 arg open, indirect invocation, etc) Show quoted text
> (Or expect them to maintain code with it)
I don't think this applies... a quirk of a project is a quirk of a project. I could take your statement and apply it to any codebase that uses Devel::Declare, or Perl5i or somesuch - it is reasonable to expect an employee to get familiar with the local dialect of perl used... Or am I missing something? Show quoted text
> b) it's *marginally* harder to maintain the code codebase because the code > to deal with the feature exists > > > The case of (IIRC) do subroutine syntax springs to mind. IIRC chromatic > calculated that 2% (or was it 4%) of the Perl grammar exists just to deal > with it. From a language-user point of view it's not getting in the way - > if you don't use it, it doesn't hurt you. But it's potentially one of the > "thousand cuts".
Being 2 (or 4%) of the grammar, and being a special case of invocation (thus likely having an effect on entersub or somesuch) - in any case - there is *tangible* technical benefit of removing this. I do not believe it would be reasonable to complain if this were removed during a *related* encounter with this part of the parser/lexer/whathaveyou. Show quoted text
> So no individual change is worth it. On its own. But the sum of quite a > few of them start to take things in the right direction. So I don't think > it's purely dogma to be removing things before they are *actively* in the > way. So there's a cost to any approach.
I actually agree with this in principle. It is the context of such changes that bothers me. I am specifically decrying "cleanup for the sake of cleanup" - when someone takes time specifically to remove deprecated features for reason no other than to "stick to the schedule". Yes, an argument can be made that removing extra code now, will make it easier for the next maintainer to work on this area. On the other hand one can make the argument that cleanup with no plan prevents the currently-assigned-janitor from seeing the big picture, thus preempting a much larger-scope cleanup that would result if a particular new feature was held in mind. In other words - all I wanted to do is raise an objection against the perceived benefit of "cleanup for the sake of cleanup". I think both sides have at this point exhausted and argumented their positions well enough, thus it is "pmpking time". What do you think? :) Cheers
CC: Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 12:26:16 +0200
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
On 27 June 2013 10:54, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: Show quoted text
> To summarize/clarify my position: An end-user has no right to complain > that a deprecated feature got in the way of something and was removed. > An end user could very well complain that a feature was gone without a > technical reason (see below).
The time to have that discussion is *before* the feature is deprecated. If there is not a sufficiently good reason to deprecate the feature then it should not be deprecated. What you are suggesting is that we can only remove deprecated features when you and some group of unnamed individuals have approved the reason for removal. I dont think that flies. Any such issues should be raised when the features is proposed for deprecation. If the pumpking, who has final decision on the matter, decides the item is deprecated then that should be sufficient. Frankly if I encountered a sufficiently long deprecated feature in part of the code I tend to work on and it got in my way in the slightest bit I would chainsaw it without question or even discussion, and would not expect any come back on it. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 20:31:06 +1000
To: demerphq <demerphq [...] gmail.com>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 990b
On Thu, Jun 27, 2013 at 12:26:16PM +0200, demerphq wrote: Show quoted text
> > What you are suggesting is that we can only remove deprecated features > when you and some group of unnamed individuals have approved the > reason for removal.
I never made such a claim. Please reread my parts of the thread and try to see my message for what it is. Show quoted text
> I dont think that flies.
I don't think so either ;) Show quoted text
> Any such issues should be raised when the features is proposed for > deprecation. If the pumpking, who has final decision on the matter, > decides the item is deprecated then that should be sufficient.
Agreed (nor ever contested) Show quoted text
> Frankly if I encountered a sufficiently long deprecated feature in > part of the code I tend to work on and it got in my way in the > slightest bit I would chainsaw it without question or even discussion, > and would not expect any come back on it.
Precisely! The whole point is that this is not the case wrt <<"". Thanks for loudly agreeing with me ;) Cheers
CC: Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 12:57:16 +0200
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.7k
On 27 June 2013 12:31, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: Show quoted text
> On Thu, Jun 27, 2013 at 12:26:16PM +0200, demerphq wrote:
>> >> What you are suggesting is that we can only remove deprecated features >> when you and some group of unnamed individuals have approved the >> reason for removal.
> > I never made such a claim. Please reread my parts of the thread and try > to see my message for what it is.
No you did. You said people have a right to complain if we remove a deprecated feature without a technical reason. Since we only mark things as deprecated for a reason what you are essentially arguing is that the complainers get final decision on whether the reason is good enough. Show quoted text
>> I dont think that flies.
> > I don't think so either ;) >
>> Any such issues should be raised when the features is proposed for >> deprecation. If the pumpking, who has final decision on the matter, >> decides the item is deprecated then that should be sufficient.
> > Agreed (nor ever contested)
So then how come you said people have a right to complain when we do what the pumpking said we [cs]hould? Show quoted text
>> Frankly if I encountered a sufficiently long deprecated feature in >> part of the code I tend to work on and it got in my way in the >> slightest bit I would chainsaw it without question or even discussion, >> and would not expect any come back on it.
> > Precisely! The whole point is that this is not the case wrt <<"". > > Thanks for loudly agreeing with me ;)
Well, just for the record, I dont think I am. For me simply wanting to clean up the documentation for here docs would be sufficient justification to remove the deprecated feature. Indeed, simply wanting to whittle down the list of deprecated features would be. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 21:08:22 +1000
To: demerphq <demerphq [...] gmail.com>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 773b
I omitted a bunch of text where you keep claiming I said things I never said (and Nicholas seemed to understand what I meant from the get-go) On Thu, Jun 27, 2013 at 12:57:16PM +0200, demerphq wrote: Show quoted text
> For me simply wanting to clean up the documentation for here docs > would be sufficient justification to remove the deprecated feature. > Indeed, simply wanting to whittle down the list of deprecated features > would be.
Right, and this kind of "aesthetically driven breakage" is what prompted me to participate in this thread in the first place. As I said elsewhere - it's "pumpking time". Note - not time for the pumpking to reevaluate a completed deprecation, but for the pumpking to clarify whether aesthetical demolition is a tenable way forward. Cheers
CC: Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 13:26:29 +0200
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.5k
On 27 June 2013 13:08, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: Show quoted text
> I omitted a bunch of text where you keep claiming I said things I never > said (and Nicholas seemed to understand what I meant from the get-go)
Dude, read your mails. You said: "An end user could very well complain that a feature was gone without a technical reason (see below)." "I still fail to see the urge to break something without a clear technical need." You use "technical" as a metric to decide if someone has a worthy reason to remove something. I posit that *any* deprecation is due to technical reasons and as such the only way that your position makes sense is to read it as implying that you get to decide if the reason is technical enough. Which IMO doesnt fly. The time to make arguments like that is when the feature is deprecated. Not when random developer decides to use their volunteer tuits to remove something we said they could remove. I would be really pissed if some developer decided to contribute their time and remove a bunch of deprecated features and you whined that there wasnt a good enough reason. I dont want developers to be discouraged doing what we already told them they could do. (As in been there, done that, it wasn't fun, and I'd like to make sure it doesnt happen to other people.) Now, if you want to join FC in arguing that a feature should be *un*deprecated that is fine, go ahead. But that is an entirely different argument to you having the right to complain if I remove something we all have already agreed can and should be removed. Yves
CC: Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 21:39:19 +1000
To: demerphq <demerphq [...] gmail.com>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 2.6k
On Thu, Jun 27, 2013 at 01:26:29PM +0200, demerphq wrote: Show quoted text
> On 27 June 2013 13:08, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
> > I omitted a bunch of text where you keep claiming I said things I never > > said (and Nicholas seemed to understand what I meant from the get-go)
> > Dude, read your mails. You said: > > "An end user could very well complain that a feature was gone without a > technical reason (see below)."
Correct - they have the right to complain. Show quoted text
> "I still fail to see the urge to break something without a clear > technical need."
Correct - I fail to see it. Show quoted text
> You use "technical" as a metric to decide if someone has a worthy > reason to remove something. I posit that *any* deprecation is due to > technical reasons and as such the only way that your position makes > sense is to read it as implying that you get to decide if the reason > is technical enough.
You keep conflating "deprecated" with "gone". The whole point I am trying to raise is that this is ridiculous. Consider my terminology: * Deprecated => may disappear down the road, warns loudly, but still there * Gone => compile time error The transition between *these two states* is what I think we should require a technical reason for. "I want to have a shorter list of deprecated stuff" is *NOT* a technical reason. It is a moronic reason. Show quoted text
> Which IMO doesnt fly. The time to make arguments > like that is when the feature is deprecated. Not when random developer > decides to use their volunteer tuits to remove something we said they > could remove. I would be really pissed if some developer decided to > contribute their time and remove a bunch of deprecated features and > you whined that there wasnt a good enough reason.
If someone (you or a new developer) decides to spend his tuits to "shorten the deprecation list" - yes I will "whine". And until rjbs says otherwise I damn well will continue to do so. Show quoted text
> I dont want developers to be discouraged doing what we already told > them they could do. (As in been there, done that, it wasn't fun, and > I'd like to make sure it doesnt happen to other people.)
Could you expand what incident are you referring to? Show quoted text
> Now, if you want to join FC in arguing that a feature should be > *un*deprecated that is fine, go ahead.
The pumpking has spoken on *that* issue[1], there is nothing to argue about. Show quoted text
> But that is an entirely different argument to you having the right to > complain if I remove something we all have already agreed can and > should be removed.
Correct - we are having this other argument now. The pumpking has not ruled on *this* argument. Cheers [1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203752.html
CC: bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 16:49:00 +0200
To: perl5-porters [...] perl.org
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 460b
On Mon, Jun 17, 2013 at 1:15 PM, Ed Avis <perlbug-followup@perl.org> wrote: Show quoted text
> For a long time Perl has issued a warning > > Use of bare << to mean <<"" is deprecated > > This has been deprecated for a very long time and it could now > be made a syntax error.
I think it may not be entirely obvious to the casual reader that this discussion is about print <<; Hello world exit 0; And not about print <<END; Hello world END exit 0; Leon
CC: demerphq <demerphq [...] gmail.com>, Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 13:21:00 -0400
To: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: Eric Brine <ikegami [...] adaelis.com>
Download (untitled) / with headers
text/plain 563b
On Thu, Jun 27, 2013 at 7:39 AM, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
Show quoted text
"I want to have a shorter list of deprecated stuff" is *NOT* a technical
reason. It is a moronic reason.

As much as I like checking items off of lists, I can't picture someone wanting that.

"I don't want people to grow accustomed to long deprecation cycles."
"I want the things we agreed should be removed to be removed."

Yves is viewing deprecation as approval for removal. The technical merits have already been evaluated. The decision to break code has already been made.




CC: Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, "Perl5 Porteros" <perl5-porters [...] perl.org>
Subject: RE: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Thu, 27 Jun 2013 18:59:38 +0000
To: demerphq <demerphq [...] gmail.com>, Peter Rabbitson <rabbit-p5p [...] rabbit.us>
From: "Konovalov, Vadim (Vadim)** CTR **" <vadim.konovalov [...] alcatel-lucent.com>
Download (untitled) / with headers
text/plain 757b
Show quoted text
> From: demerphq > For me simply wanting to > clean up the documentation for here docs would be sufficient > justification to remove the deprecated feature. Indeed, simply wanting > to whittle down the list of deprecated features would be.
in reality - documentation will be opposite to be cleaned up: there will be "starting from version x.y.z this is now differently", how thoroughly currently is. regarding topic itself, my feeling of reading docs some 15th years ago was that its absolutely fine to omit double quotes and this is treated as double quotes. Whether it was FMTYENTK or somewhere else I can't remember. Personaly, I would prefer not to have feature deprecated and removed, but in case it will be - ok, let it be..... Regards, Vadim.
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Subject: RE: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 19:02:36 +0000
To: Leon Timmermans <fawaka [...] gmail.com>, "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: "Konovalov, Vadim (Vadim)** CTR **" <vadim.konovalov [...] alcatel-lucent.com>
Download (untitled) / with headers
text/plain 350b
Show quoted text
> From: Leon Timmermans > I think it may not be entirely obvious to the casual reader that this > discussion is about > > print <<; > Hello world > > exit 0; > > And not about > > print <<END; > Hello world > END > exit 0;
wow thanks for letting know, :) I wish I see the message couple of minutes earlier :):)
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 21:44:13 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 2.1k
* Peter Rabbitson <rabbit-p5p@rabbit.us> [2013-06-27 09:15]: Show quoted text
> By removing stuff solely to "honor a promise" is creating work for > darkpan users with the sole benefit of pleasing someone aesthetically. > > A quote of the irc.perl.org#dbic-cabal topic seems relevant: >
> > deprecated modules get deleted when they cause a problem and not > > before
Historically, there has been a problem in removing features that had been marked deprecated for so long that people stopped caring about their status as deprecated. The point of tension here, to which a solution would be welcome if you can propose one, is this: is there a way to extinguish its use in newly written code? I.e. it’s fine for now if it keeps working in code that has already been written – we don’t want to break anyone’s existing stuff needlessly. At the same time, in the ideal case, not a single new use of this feature would be introduced to the world anywhere. That way, the investment of people who used it in the past is safe- guarded until such time as it gets in the way – but, at the same time, its eventual removal is not jeopardised by the length of time between the moments of deprecation and removal due to continuing increase in its use. In the ideal case, the moment something is marked deprecated, the maximum cost of its removal is frozen at that point in time. I don’t think this is possible to achieve. The realm of the possible here is a spectrum, and your proposal lies at the very end on one side of it. The other extreme in this spectrum is not (to my mind) a reasonable position, but while the one you occupy is, I don’t know that it’s necessarily the most reasonable one on the entire spectrum. It’s not necessarily a one-dimensional spectrum, mind you. Moving toward Yves’ end is one way to have a stabilising effect on the cost of removal but not necessarily the only solution. The question is, what approaches can be taken to try to satisfy as much of both criteria as possible? (I.e., maximise the safety margin for old users while suppressing further cost from accruing against its removal.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Thu, 27 Jun 2013 14:48:47 -0500
To: perlbug-followup [...] perl.org
From: David Nicol <davidnicol [...] gmail.com>
Download (untitled) / with headers
text/plain 639b


On Tue, Jun 25, 2013 at 10:43 PM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Tue Jun 25 18:12:46 2013, davidnicol@gmail.com wrote:
>
> Me too! And while we're on the subject, it should allow space between the
> angle brackets and the bareword terminator.

That would break << cmp <<, which currently works:

$ perl  -Xle 'print << cmp <<; ' -ea -e '' -eb -e '' -e ''
-1
$ perl  -Xle 'print << cmp <<; ' -eb -e '' -ea -e '' -e ''
1

I think that's what you said the last time, too, so I had the patch special-case all
the bareword infix operators, including eq, lt, gt, ge, le as well as cmp.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 959b
On Wed Jun 26 16:32:27 2013, perl.p5p@rjbs.manxome.org wrote: Show quoted text
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-06- > 17T09:33:08]
> > I would like to see that *un*deprecated. I see no reason why that > > syntax should cause any problems. It doesn’t make anything less > > ambiguous to remove it. (On top of that, it looks nice!)
> > I slept on this for a few nights, because you may well be correct that > it > introduces no syntactical ambiguity, and because I do generally > believe that 𝑑𝑒 > 𝑔𝑢𝑠𝑡𝑖𝑏𝑢𝑠 𝑛𝑜𝑛 𝑒𝑠𝑡 𝑑𝑖𝑠𝑝𝑢𝑡𝑎𝑛𝑑𝑢𝑚... but no. I
think it's just the sort of Show quoted text
> facepalmingly "straightforward" syntax that has no real value but to > further > confuse the uninitiated. Thirty-two thousand eight hundred and nine > shibboleths are enough. We can do without restoring one more.
In that case I have rerejected ticket #66686. -- Father Chrysostomos
CC: perl5-porters [...] perl.org
Subject: Re: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error
Date: Fri, 28 Jun 2013 07:49:02 +1000
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
From: Peter Rabbitson <rabbit-p5p [...] rabbit.us>
Download (untitled) / with headers
text/plain 1.9k
On Thu, Jun 27, 2013 at 09:44:13PM +0200, Aristotle Pagaltzis wrote: Show quoted text
> * Peter Rabbitson <rabbit-p5p@rabbit.us> [2013-06-27 09:15]:
> > By removing stuff solely to "honor a promise" is creating work for > > darkpan users with the sole benefit of pleasing someone aesthetically. > > > > A quote of the irc.perl.org#dbic-cabal topic seems relevant: > >
> > > deprecated modules get deleted when they cause a problem and not > > > before
> > Historically, there has been a problem in removing features that had > been marked deprecated for so long that people stopped caring about > their status as deprecated. > > The point of tension here, to which a solution would be welcome if you > can propose one, is this: is there a way to extinguish its use in newly > written code?
Is this really the point of tension though? Let's take a much less obscure example: a user buys a fresh book about perl and proceeds using the shiny ~~ syntax. A set of loud warnings is emitted. If the user proceeds writing code *despite* these warnings - is it really anyone elses problem at this point...? Maybe the argument here is "but not everyone uses warnings", which is somewhat true. In an ideal world lexical warnings would be a tri-state, with some warnings (deprecation, and reeeeeally ominous ones) being on by default, and others being off by default, with the usual control with use/no warnings. We don't have that. However what we have is an army of modules which unapologetically import pragmas into the callers namespace. So many in fact that it is becoming increasingly unlikely that new code will not get warnings implicitly turned on in many parts of the source. This still leaves us with the problem of oneliners which are not instrumented wrt deprecation warnings. I concede I do not have a good solution for this, and as such chalking this up for "the cost of doing business" seems the only solutions. Still my question stands - is the threat of new code using *visibly* deprecated features really that severe...? Cheers
CC: Peter Rabbitson <rabbit-p5p [...] rabbit.us>, Nicholas Clark <nick [...] ccl4.org>, Ed Avis <eda [...] waniasset.com>, Perl5 Porteros <perl5-porters [...] perl.org>
Subject: Re: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Fri, 28 Jun 2013 11:56:50 +0200
To: "Konovalov, Vadim (Vadim)** CTR **" <vadim.konovalov [...] alcatel-lucent.com>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.3k
On 27 June 2013 20:59, Konovalov, Vadim (Vadim)** CTR ** <vadim.konovalov@alcatel-lucent.com> wrote: Show quoted text
>> From: demerphq >> For me simply wanting to >> clean up the documentation for here docs would be sufficient >> justification to remove the deprecated feature. Indeed, simply wanting >> to whittle down the list of deprecated features would be.
> > in reality - documentation will be opposite to be cleaned up: there will be > "starting from version x.y.z this is now differently", how thoroughly currently is.
I can see what you mean, but it is besides the point for me. The point for me is that "technical reason" is poorly defined, such that one can consider "simplify documentation" as technical, or not, as suits ones preferences and biases. Which for me utterly undermines its use in determining whether a deprecated feature should actually be removed. I persist in the belief that any argument about whether a feature should be removed or not should be determined *prior* to deprecation. Deprecation means "this will be removed", not "maybe at some point in the future we will find a reason to remove this so we are marking it as deprecated now so that once we have the argument about whether there is a good reason for removing it or not we can". The latter to me is not a framework for getting stuff done. Its like veto politics, a perfect way to make it impossible to get anything done. Yves
Subject: RE: What does "deprecated" mean? (was: [perl #118511] Use of bare << to mean <<"" is deprecated - make a hard error)
Date: Fri, 28 Jun 2013 11:14:54 +0000
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: Ed Avis <eda [...] waniasset.com>
Download (untitled) / with headers
text/plain 559b
Show quoted text
>I persist in the belief that any argument about whether a feature >should be removed or not should be determined *prior* to deprecation.
Agreed, and further, if there is not a 'technical reason' (whatever that means) for removing it then it should not be marked as deprecated. Show quoted text
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
______________________________________________________________________
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.9k
This is another of those situations that, I think, isn't really as straightforward as it might seem. Here are some facts and observations, carelessly mingled: * use of bare << to mean "" has been deprecated since 5.002 (1996-02) * starting then, it warned under "use warnings" * starting it 5.12.0, it warned even without warnings requested (2010-04) * when we deprecate things, we do it because we have a reason to actually remove it * if we just think it's a bad idea, we "discourage" it instead * use of bare << to mean "" has been *deprecated* since 5.002 (1996-02) * ... but this discourage/deprecate distinction is a recent innovation * records of the discussion of this deprecation, if any, are not easy to find * ...but we know that we're not talking about dropping this behavior to make room for another * rjbs has acknowledged thinking that this is a nasty piece of syntax, which will lead to confusion * somewhere, out there, there is code that will be busted if this code is removed So, if we remove this behavior, something breaks, but the language is otherwise somehow better. What's the actual tradeoff? Code that will break was either written before 1996, written without consulting the documentation, or written despite the documentation's warnings. It doesn't "use warnings" or nobody is looking at its warning output. It isn't running on perl v5.12.0 or later, or "no warnings" is there to shut up the warnings. So, the code that will break will be code that expressly turned off warnings, or is being run ignoring the warnings, or is being upgraded from 5.10.x (or earlier) to 5.20.x directly, meaning a minimum of five years between releases used. The solution in all cases is to replace << with <<"" The benefit to weigh against these costs are: (1) the removal of a very small amount of code; (2) the removal of a very small amount of documentation; (3) the proof that when we say "deprecated," we mean it really will go away; (4) the resolution of a pending deprecation, which otherwise will float in the air. I find (3) to be the least compelling on its own. It's okay to be wrong about having deprecated something. We can take as long as we like. It's more compelling in conjunction with (4). How often are we going to have this conversation about bare <<? We just had it two years ago: http://www.nntp.perl.org/group/perl.perl5.porters/2009/06/msg147438.html Sometimes, it's good to take a nice long time to figure out the right answer. Sometimes, that answer needs to come so that there is no more lingering question. It's an issue of keeping the number of open questions low. I see no value in keeping "bare <<" heredocs around, other than avoiding the breakage of a presumably small amount of code that, frankly, has had every opportunity to reform. There is no future in which I see the feature being appreciated and spared from the looming threat of removal. We should put it out of its misery and move on, freeing up discussion time for things of greater value. -- rjbs
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 233b
On Sun Jun 30 20:31:15 2013, rjbs wrote: Show quoted text
> (1) the removal of a > very small amount of code;
For the record, there would be no code removal. It takes more code to prevent << from working than to allow it. -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
I'd like to ask a simple question. Maybe I'm misunderstanding something obvious, but I don't see where/when this was *ever* deprecated or any warnings issued. Yes, Perl Best Practices proclaimed that double-quoting better showed intent. But I've never seen any deprecation warning, or anything in the docs that says this is deprecated. Running Perl 5.18.0 from perlbrew: % ./heredoc-test.pl Version=5.018000 Here's a quote. % cat heredoc-test.pl #!/bin/env perl use strict; use warnings; print <<END; Version=$] Here's a quote. END The Perl 5.18.0 perlop man page says: <<EOF A line-oriented form of quoting is based on the shell "here-document" syntax. Following a "<<" you specify a string to terminate the quoted material, and all lines following the current line down to the terminating string are the value of the item. The terminating string may be either an identifier (a word), or some quoted text. An unquoted identifier works like double quotes. There may not be a space between the "<<" and the identifier, unless the identifier is explicitly quoted. (If you put a space it will be treated as a null identifier, which is valid, and matches the first empty line.) The terminating string must appear by itself (unquoted and with no surrounding whitespace) on the terminating line. No mention of deprecation anywhere that I can see. What am I missing? If it had really been warned about back to Perl 5.12, and if it really simplifies the grammar, I wouldn't mind it being gone. But it will definitely break a ton of code. At least it's easy to fix, though. Yes according to Father Chrysostomos' last comment, there's no internal code simplification waiting as a reward for all the breakage. Again, what am I missing? Where is this deprecation notice? If I hadn't come across this thread I would think there's absolutely nothing wrong with bareword heredocs except that Damian Conway's aesthetic preference was to avoid them. I work with other Perl programmers who likewise have never heard of this. Jon
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 298b
Goodness. If this really means literally <<"" vs. <<"END" then yeah, ignore my comment! https://rt.perl.org/rt3/Ticket/Display.html?id=118511#txn-1228753 Sorry for the misunderstanding. I'm commenting on the blog post that misled me here: http://perlmaven.com/bare-here-documents-are-deprecated


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org