New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Old package separator syntax #16270
Comments
From @epaFor a long time the normal way to write the package separator in variable names has been :: but the older ' form is still accepted. (I believe that the newer form came in with Perl 5 but I am not sure; anyhow it certainly predates my first use of Perl twenty years ago.) A gotcha with ' has long been mentioned in the Camel book: "This is $owner's house" That parses the same as $owner::s and you get a warning at run time, so you can work out what is going on, but it is quite strange if you didn't know about the old ' package separator syntax. (I did know about it but I still fell into the trap of writing code like the above.) Might it be time to mark the old package separator as deprecated? That would allow a compile time (rather than run time) diagnostic on the use of it. Eventually, once the old syntax is removed, "$owner's house" would work as expected. The suggestion to deprecate things can trigger fierce discussion, so as a fallback position I would advocate a warning when the ' form is used inside a doublequote-interpolated string. Flags: category=core severity=low Site configuration information for perl 5.22.2: Configured by Red Hat, Inc. at Fri Nov 4 14:35:02 UTC 2016. Summary of my perl5 (revision 5 version 22 subversion 2) configuration: Platform: osname=linux, osvers=4.7.9-200.fc24.x86_64, archname=x86_64-linux-thread-multi uname='linux buildvm-12.phx2.fedoraproject.org 4.7.9-200.fc24.x86_64 #1 smp thu oct 20 14:26:16 utc 2016 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Doptimize=none -Dccflags=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Dldflags=-Wl,-z,relro -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.22.2 -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 use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize=' -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='5.3.1 20160406 (Red Hat 5.3.1-6)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags ='-Wl,-z,relro -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib libs=-lpthread -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.22.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.22' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro ' cccdlflags='-fPIC', lddlflags='-shared -Wl,-z,relro -L/usr/local/lib -fstack-protector-strong' Locally applied patches: Fedora Patch1: Removes date check, Fedora/RHEL specific Fedora Patch3: support for libdir64 Fedora Patch4: use libresolv instead of libbind Fedora Patch5: USE_MM_LD_RUN_PATH Fedora Patch6: Skip hostname tests, due to builders not being network capable Fedora Patch7: Dont run one io test due to random builder failures Fedora Patch15: Define SONAME for libperl.so Fedora Patch16: Install libperl.so to -Dshrpdir value Fedora Patch22: Document Math::BigInt::CalcEmu requires Math::BigInt (CPAN RT#85015) Fedora Patch26: Make *DBM_File desctructors thread-safe (RT#61912) Fedora Patch27: Make PadlistNAMES() lvalue again (CPAN RT#101063) Fedora Patch28: Make magic vtable writable as a work-around for Coro (CPAN RT#101063) Fedora Patch29: Fix duplicating PerlIO::encoding when spawning threads (RT#31923) Fedora Patch30: Do not let XSLoader load relative paths (CVE-2016-6185) Fedora Patch31: Avoid loading optional modules from default . (CVE-2016-1238) Fedora Patch32: Fix a crash in lexical scope warnings (RT#128597) Fedora Patch33: Do not mangle errno from failed socket calls (RT#128316) Fedora Patch34: Fix crash in "evalbytes S" (RT#129196) Fedora Patch35: Fix crash in "evalbytes S" (RT#129196) Fedora Patch36: Fix crash in "evalbytes S" (RT#129196) Fedora Patch37: Fix crash in splice (RT#129164, RT#129166, RT#129167) Fedora Patch38: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267) Fedora Patch39: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267) Fedora Patch40: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267) Fedora Patch41: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267) Fedora Patch42: Fix string overrun in Perl_gv_fetchmethod_pvn_flags (RT#129267) Fedora Patch43: Fix crash when matching UTF-8 string with non-UTF-8 substrings (RT#129350) Fedora Patch44: Fix parsing perl options in shell bang line (RT#129336) Fedora Patch45: Fix firstchar bitmap under UTF-8 with prefix optimization (RT#129950) Fedora Patch46: Avoid infinite loop in h2xs tool if enum and type have the same name (RT130001) Fedora Patch47: Fix stack handling when calling chdir without an argument (RT#129130) Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux @INC for perl 5.22.2: /home/eda/lib64/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.22.2: 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:/home/eda/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/sbin:/home/eda/.local/bin:/home/eda/bin:/sbin:/usr/sbin:/sbin:/usr/sbin PERL5LIB=/home/eda/lib64/perl5/ PERL_BADLANG (unset) SHELL=/bin/bash |
From @epaRepeating message text since not shown in web interface. For a long time the normal way to write the package separator in variable names has been :: but the older ' form is still accepted. A gotcha with ' has long been mentioned in the Camel book: "This is $owner's house" That parses the same as $owner::s and you get a warning at run time, so you can work out what is going on, but it is quite strange if you didn't know about the old ' package separator syntax. (I did know about it but I still fell into the trap of writing code like the Might it be time to mark the old package separator as deprecated? The suggestion to deprecate things can trigger fierce discussion, so as a fallback position I would advocate a warning when the ' Flags: Site configuration information for perl 5.22.2: Configured by Red Hat, Inc. at Fri Nov 4 14:35:02 UTC 2016. Summary of my perl5 (revision 5 version 22 subversion 2) configuration: Locally applied patches: @INC for perl 5.22.2: Environment for perl 5.22.2: |
The RT System itself - Status changed from 'new' to 'open' |
From gdg@zplane.comEd Avis <perlbug-followup@perl.org> [2017-11-22 08:04:05 -0800]:
+1 from the Moron Gallery for deprecation, or improving the emitted message This is one of our favorite forms of periodic self-mystification: We do it |
From @exodistI agree that it would be good to get rid of ' as a package separator, that Off the top of my head: isn't (isn::t) as defined by Test::More since the dawn of time (I did not This also bring up the point that a lot of modules that take module names Here is a silly one that will still work, but the intended usage form That said, I think the benefit of ditching the ' package separator Final note: I wonder if it something that can be turned off via a pragma? -Chad On Wed, Nov 22, 2017 at 8:04 AM, Ed Avis <perlbug-followup@perl.org> wrote:
|
From zefram@fysh.orgEd Avis wrote:
It's an the fuzzy boundary of what we consider deprecatable. It's rarely -zefram |
From @cpansproutOn Wed, 22 Nov 2017 11:43:11 -0800, zefram@fysh.org wrote:
I have continued to use it, because it’s shorter and quicker to type than ::. I would be all in favour of the proposed warning, though, if only to allay the threat of deprecation.
I agree. -- Father Chrysostomos |
From @cpansproutOn Wed, 22 Nov 2017 10:11:50 -0800, exodist7@gmail.com wrote:
I looked into that several years ago. Making it dependent on a pragma would add more conditions to fairly hot code (gv_fetchsv). It would probably slow things down (and cause bugs at the same time) without much benefit. -- Father Chrysostomos |
From @exodistOn Wed, Nov 22, 2017 at 1:03 PM, Father Chrysostomos via RT <
Thanks, sounds like it is not worth it then. |
From @epa
Viewed in abstract terms of language design, the ' package separator is rather weird. The ' character, almost everywhere in Unix and in Perl, is part of a matched delimiter. For it to sometimes appear solo is strange. Moreover, the need to parse it as a package separator sometimes affects its use as a string delimiter. sub foo { say $_[0] } foox"hi"; # String found where operator expected It's not that hot as a synonym for :: either: sub foo' {} # Illegal declaration of subroutine main::foo sub 'foo { say $_[0] } At the very least, this argues for forbidding the ' syntax at the start and end of identifiers. (I would also say that foo'hi' not working is a bug, when foo"hi" is fine.) But the more important point is, this syntactic weirdness and possible ambiguity is another one to combine with all the other idiosyncrasies to result in crazy-sounding syntax errors or bizarre parses of a fairly simple typo. We've all had these WTF moments when writing Perl code; a simple change causes the parser to spew out error messages over several seemingly unrelated lines of code, with a bit of headscratching required (especially for the novice) to work out that it was all down to a bit of misplaced punctuation a couple of lines earlier. A lot of this is inevitable. A lot of the ambiguities in the grammar are the price we pay for richness, expressivity and concision. But this particular one doesn't enrich the language or (except for golfing) let you write shorter code. To regularize ' so that it follows broadly the same rules as " would be a small but noticeable improvement.
|
From @cpansproutOn Wed, 22 Nov 2017 13:03:28 -0800, sprout wrote:
I have added this warning in commit 2cb35ee: $ ./perl -cwe '$name = <>; print "I visited $name'\''s house.\n"' -- Father Chrysostomos |
From @exodistWhat type of warning category is it? I have at least 1 test file where I On Sun, Nov 26, 2017 at 1:42 PM, Father Chrysostomos via RT <
|
From @cpansproutOn Sun, 26 Nov 2017 15:10:45 -0800, exodist7@gmail.com wrote:
syntax -- Father Chrysostomos |
From @epaThanks for adding this warning, Father C. That will explain a longstanding gotcha, although it doesn't remove it. If the perl5-porters think it is worthwhile to move towards removing the old package separator syntax, I suggest that a first step would be to issue a deprecation warning when used in variable names, but continue to allow it for barewords. $foo'bar; # deprecated I also suggest that at some point in the future when the ' is deprecated altogether, even in subroutine names, modules providing cute names like C<isn't> could do so with a simple source filter. |
From @kentfredricOn 28 November 2017 at 02:55, Ed Avis via RT <perlbug-followup@perl.org> wrote:
Please no. That is far worse than leaving this feature in place. -- KENTNL - https://metacpan.org/author/KENTNL |
From @LeontOn Mon, Nov 27, 2017 at 2:55 PM, Ed Avis via RT <perlbug-followup@perl.org>
For what benefit? I see a benefit in removing them in quoted strings, because of the odds Leon |
From @epaAs I say, it's "if". If people think that the older package separator syntax should be deprecated and eventually removed. That is something I would support, and I gave some arguments for it earlier. but there are certainly arguments for keeping it around. *If* the perl5-porters do want to put the old syntax on the deprecation path, I suggest that the first step would be in variable names like C<$a'b>. The use in subroutine names could be left as a later step, partly because of existing code with isn't and perhaps other apostrophized names (Acme::Don't). |
From @demerphqOn 27 November 2017 at 16:22, Leon Timmermans <fawaka@gmail.com> wrote:
If it's worth removing them from quoted strings then it's worth Yves -- |
From @andk
> If it's worth removing them from quoted strings then it's worth And your argument is? -- |
From @demerphqOn 27 Nov 2017 20:25, "Andreas Koenig" <
> If it's worth removing them from quoted strings then it's worth And your argument is? Consistency. Either apostrophe is a valid replacement for colon-colon or Yves Yves |
From @LeontOn Tue, Nov 28, 2017 at 12:02 AM, demerphq <demerphq@gmail.com> wrote:
Consistency is useful when one needs to explain people how something works, Leon |
From @demerphqOn 28 Nov 2017 00:46, "Leon Timmermans" <fawaka@gmail.com> wrote: On Tue, Nov 28, 2017 at 12:02 AM, demerphq <demerphq@gmail.com> wrote:
Consistency is useful when one needs to explain people how something works, And if that's our policy we should just deprecate and remove it. Yves |
From @xsawyerxI think this captures my thoughts on this at the moment. Deprecating is a fragile process with which we should be judicious. We My perspective here is that, while this is not valuable syntax, it is Regarding Yves' comment on consistency, I think Ed showed it is already On 11/22/2017 09:42 PM, Zefram wrote:
|
From @xenuOn Tue, 28 Nov 2017 14:29:14 +0200
Existence of ' package separator sometimes causes extremely misleading use Moose; has erdef => ( has cxxc => ( Can you spot the real error? |
From @cpansproutOn Fri, 01 Dec 2017 20:03:28 -0800, me@xenu.pl wrote:
Yes, I saw it immediately. But what you have pointed out is not a problem with ' per se. There is a logic error in toke.c (a separate bug), causing this error to suppress others. We can fix that. -- Father Chrysostomos |
From @cpansproutOn Fri, 01 Dec 2017 20:03:28 -0800, me xenu.pl wrote:
Try this example: use Moose; has erdef => ( has cxxc => ( It does the same unhelpful thing. (Bad name after Foo::.) It’s not specific to '. In bleadperl, as of commit 76b3530 (just committed), your example gives: Bareword found where operator expected at - line 10, near "isa => 'Int" That ‘Do you need to predeclare’ message is not helpful, but all I did was switch around the ‘Bareword found’ and ‘Bad name’ error messages. -- Father Chrysostomos |
From @xenuOn Mon, 04 Dec 2017 15:47:22 -0800
Thank you, now it's much better! |
Migrated from rt.perl.org#132485 (status was 'open')
Searchable as RT132485$
The text was updated successfully, but these errors were encountered: