Perl should warn or die on mathematical operations on reference implicitly converted to an integer

p5pRT commented 15 years ago

Migrated from rt.perl.org#70043 (status was 'open')

Searchable as RT70043$

p5pRT commented 15 years ago

From goldstei@ugcs.caltech.edu

I'm taking bets on if they think this is a bug or not.

My vote is with no.

From Joshua David Goldstein \goldstei@ugcs\.caltech\.edu\, Tue\, Oct 27\, 2009 at 12:01:03AM -0700:

This is a bug report for perl from goldstei@ugcs.caltech.edu\, generated with the help of perlbug 1.36 running under perl 5.10.0.

----------------------------------------------------------------- [Please enter your report here]

I've found that perl will allow you to do all sorts of unreasonable operations on references. Here's an example: ------- #!/usr/bin/perl -w use strict; my $foo = sub { return 0 }; my $bar = 1; print "foo: $foo\, bar: $bar\n"; my $baz = $foo + $bar; print "baz: $baz\n"; ------- running this produces the output: ------- foo: CODE(0x1c60460)\, bar: 1 baz: 29754465 -------

Now the 'perlref' manpage says: "Using a reference as a number produces an integer representing its storage location in memory. The only useful thing to be done with this is to compare two references numerically to see whether they refer to the same location."

It's easy to see why you'd want to convert to an integer for reference testing\, but even the documentation says that there's not much useful you can do besides that. There is never a case in which this is valid behavior or what the user intended to do\, so it shouldn't be allowed to happen. Why do I not see an error here that says\, 'Error: Adding an integer to a reference' or something similar?

[Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.10.0:

Configured by Debian Project at Fri Aug 28 22:30:10 UTC 2009.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux\, osvers=2.6.26-2-amd64\, archname=i486-linux-gnu-thread-multi uname='linux puccini 2.6.26-2-amd64 #1 smp fri aug 14 07:12:04 utc 2009 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des' hint=recommended\, useposix=true\, d_sigaction=define useithreads=define\, usemultiplicity=define useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef use64bitint=undef\, use64bitall=undef\, uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\, optimize='-O2 -g'\, cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion=''\, gccversion='4.3.2'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=4\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/lib64 libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.7.so\, so=so\, useshrplib=true\, libperl=libperl.so.5.10.0 gnulibc_version='2.7' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E' cccdlflags='-fPIC'\, lddlflags='-shared -O2 -g -L/usr/local/lib'

Locally applied patches:

--- @INC for perl 5.10.0: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .

--- Environment for perl 5.10.0: HOME=/afs/.ugcs/user/goldstei LANG=en_US LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/afs/.ugcs/user/goldstei/ugcs2/scripts:/usr/ug/bin:/usr/ug/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/ug/adm/bin/scripts:/ug/adm/bin/:/usr/X11R6/bin:/afs/.ugcs/user/goldstei/bin:/afs/.ugcs/user/goldstei/maple10/bin:/mnt/cresol/cresol/ufs/egnor/i386-linux2/bin:/usr/ug/share/scripts:/afs/.ugcs/user/goldstei/ugcs2/scripts:/usr/ug/bin:/usr/ug/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/ug/adm/bin/scripts:/ug/adm/bin/:/usr/X11R6/bin:/afs/.ugcs/user/goldstei/bin:/afs/.ugcs/user/goldstei/maple10/bin:/mnt/cresol/cresol/ufs/egnor/i386-linux2/bin:/usr/ug/share/scripts:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games PERL_BADLANG (unset) SHELL=/bin/zsh _______________________________________________ Sysadmins mailing list Sysadmins@ugcs.caltech.edu https://hermes.ugcs.caltech.edu/cgi-bin/mailman/listinfo/sysadmins

-- Joshua Goldstein goldstei@ugcs.caltech.edu (626)-529-6964

p5pRT commented 15 years ago

From @ap

* goldstei@ugcs.caltech.edu (via RT) \perlbug\-followup@perl\.org [2009-10-27 09:35]:

I'm taking bets on if they think this is a bug or not.

My vote is with no.

Only in semantic nitpicking in that it works as designed.

As far as I’m concerned that design is indeed broken\, though.

Along similar lines I’d also like to eventualy see it become a fatal error to stringify a reference implicitly\, since that often happens by accident and the resulting string is useless in most circumstances\, but the silent apparent success of the operation leads to errors only turning up far away from where the stringification (ie. the real mistake) actually happened.

I don’t know how popular this opinion is\, though.

Regards\, -- Aristotle Pagaltzis

p5pRT commented 15 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 15 years ago

From @xdg

On Tue\, Oct 27\, 2009 at 6:41 AM\, Aristotle Pagaltzis \pagaltzis@gmx\.de wrote:

Along similar lines I’d also like to eventualy see it become a fatal error to stringify a reference implicitly\, since that often happens by accident and the resulting string is useless in most circumstances\, but the silent apparent success of the operation leads to errors only turning up far away from where the stringification (ie. the real mistake) actually happened.

I don’t know how popular this opinion is\, though.

To me\, it seems consistent with the idea "use strict 'refs'" -- if strictures are on\, stringifying or numifying a reference should be a fatal error. If someone needs it\, they should use refaddr anyway because of overloading. So to clarify\, it should be fatal *unless* it's a blessed object with numification or stringification overloading.

-- David

p5pRT commented 15 years ago

From @nwc10

On Tue\, Oct 27\, 2009 at 07:00:07AM -0400\, David Golden wrote:

On Tue\, Oct 27\, 2009 at 6:41 AM\, Aristotle Pagaltzis \pagaltzis@gmx\.de wrote:

Along similar lines I???d also like to eventualy see it become a fatal error to stringify a reference implicitly\, since that often happens by accident and the resulting string is useless in most circumstances\, but the silent apparent success of the operation leads to errors only turning up far away from where the stringification (ie. the real mistake) actually happened.

I don???t know how popular this opinion is\, though.

To me\, it seems consistent with the idea "use strict 'refs'" -- if strictures are on\, stringifying or numifying a reference should be a fatal error. If someone needs it\, they should use refaddr anyway because of overloading. So to clarify\, it should be fatal *unless* it's a blessed object with numification or stringification overloading.

Which breaks existing code that uses strict\, and the idiom of using the stringification of references as hash keys.

Nicholas Clark

p5pRT commented 15 years ago

From @abigail

On Tue\, Oct 27\, 2009 at 11:41:45AM +0100\, Aristotle Pagaltzis wrote:

Along similar lines I’d also like to eventualy see it become a fatal error to stringify a reference implicitly\, since that often happens by accident and the resulting string is useless in most circumstances\, but the silent apparent success of the operation leads to errors only turning up far away from where the stringification (ie. the real mistake) actually happened.

I use often stringified references. Either by printing them (debugging tool)\, or as hash keys. If I want a quick and dirty implementation of inside out objects and I'm using a pre-5.10 perl\, I use objects as keys keys directly.

Forbidding anything that may lead to an error somewhere else in the code would quickly leave us with no construct in the language at all.

Abigail

p5pRT commented 15 years ago

From @xdg

On Tue\, Oct 27\, 2009 at 7:05 AM\, Nicholas Clark \nick@ccl4\.org wrote:

On Tue\, Oct 27\, 2009 at 07:00:07AM -0400\, David Golden wrote:

To me\, it seems consistent with the idea "use strict 'refs'" -- if strictures are on\, stringifying or numifying a reference should be a fatal error. If someone needs it\, they should use refaddr anyway because of overloading. So to clarify\, it should be fatal *unless* it's a blessed object with numification or stringification overloading.

Which breaks existing code that uses strict\, and the idiom of using the stringification of references as hash keys.

That "idiom" is an accident waiting to happen because of overloading. It should at least warn. But I actually think it should be fatal under strictures -- that's the whole point of strictures. You can turn them off and be unsafe\, but you need to know what you're doing. Now that Scalar::Util is core\, refaddr() is available and should always be used to get a reference address. (refaddr should *not* warn/die\, because it's explicit.)

-- David

p5pRT commented 15 years ago

From @pjcj

On Tue\, Oct 27\, 2009 at 11:05:11AM +0000\, Nicholas Clark wrote:

On Tue\, Oct 27\, 2009 at 07:00:07AM -0400\, David Golden wrote:

On Tue\, Oct 27\, 2009 at 6:41 AM\, Aristotle Pagaltzis \pagaltzis@gmx\.de wrote:

Along similar lines I???d also like to eventualy see it become a fatal error to stringify a reference implicitly\, since that often happens by accident and the resulting string is useless in most circumstances\, but the silent apparent success of the operation leads to errors only turning up far away from where the stringification (ie. the real mistake) actually happened.

I don???t know how popular this opinion is\, though.

To me\, it seems consistent with the idea "use strict 'refs'" -- if strictures are on\, stringifying or numifying a reference should be a fatal error. If someone needs it\, they should use refaddr anyway because of overloading. So to clarify\, it should be fatal *unless* it's a blessed object with numification or stringification overloading.

Which breaks existing code that uses strict\, and the idiom of using the stringification of references as hash keys.

And would also reduce the enjoyment we all get at seeing HASH(0x81531d8) on a web page somewhere.

-- Paul Johnson - paul@pjcj.net http://www.pjcj.net

p5pRT commented 15 years ago

From @xdg

On Tue\, Oct 27\, 2009 at 7:21 AM\, Abigail \abigail@abigail\.be wrote:

I use often stringified references. Either by printing them (debugging tool)\, or as hash keys. If I want a quick and dirty implementation of inside out objects and I'm using a pre-5.10 perl\, I use objects as keys keys directly.

Forbidding anything that may lead to an error somewhere else in the code would quickly leave us with no construct in the language at all.

Fortunately\, you'd still be able to do so in pre-5.10 perl. :-)

Making reference stringification a warning wouldn't stop quick and dirty debugging\, which is why I say that would\, at a minimum\, be an improvement on the current situation.

I might be in favor of refaddr() moving into core from Scalar::Util so it's always available even if module loading is borked.

-- David

p5pRT commented 15 years ago

From @abigail

On Tue\, Oct 27\, 2009 at 07:21:45AM -0400\, David Golden wrote:

On Tue\, Oct 27\, 2009 at 7:05 AM\, Nicholas Clark \nick@ccl4\.org wrote:

On Tue\, Oct 27\, 2009 at 07:00:07AM -0400\, David Golden wrote:

To me\, it seems consistent with the idea "use strict 'refs'" -- if strictures are on\, stringifying or numifying a reference should be a fatal error. If someone needs it\, they should use refaddr anyway because of overloading. So to clarify\, it should be fatal *unless* it's a blessed object with numification or stringification overloading.

Which breaks existing code that uses strict\, and the idiom of using the stringification of references as hash keys.

That "idiom" is an accident waiting to happen because of overloading.

What overloading? ;-)

*I* know when my code uses overloading. It usually doesn't. It shouldn't warn because there might be an issue if overloading is used.

It should at least warn. But I actually think it should be fatal under strictures -- that's the whole point of strictures.

Really? Should strict also forbid using a string as a number? Or a float as a integer? A string as a regular expression?

I consider 'auto casting' a *feature* of Perl. One I use on a regular basis. I don't think Perl should start warning on one of its nicest features.

                                                       You can
turn them off and be unsafe\, but you need to know what you're doing. Now that Scalar::Util is core\, refaddr() is available and should always be used to get a reference address. (refaddr should *not* warn/die\, because it's explicit.)

IMO\, warnings for situations that are *likely* to be errors are good. Warnings for situations that *maybe under additional conditions* be an error are annoying. Warnings for coding style should be in a linter like perlcritic.

Abigail

p5pRT commented 15 years ago

From @abigail

On Tue\, Oct 27\, 2009 at 07:27:01AM -0400\, David Golden wrote:

On Tue\, Oct 27\, 2009 at 7:21 AM\, Abigail \abigail@abigail\.be wrote:

I use often stringified references. Either by printing them (debugging tool)\, or as hash keys. If I want a quick and dirty implementation of inside out objects and I'm using a pre-5.10 perl\, I use objects as keys keys directly.

Forbidding anything that may lead to an error somewhere else in the code would quickly leave us with no construct in the language at all.

Fortunately\, you'd still be able to do so in pre-5.10 perl. :-)

Making reference stringification a warning wouldn't stop quick and dirty debugging\, which is why I say that would\, at a minimum\, be an improvement on the current situation.

I might be in favor of refaddr() moving into core from Scalar::Util so it's always available even if module loading is borked.

Ah\, but perhaps

$hash {refaddr $ref}

should warn as well\, because it's a disaster waiting to happen. You know\, in a thread\, the address might change. And post 5.10\, you have fieldhashes\, which you should use instead of refaddr anyway. ;-)

Abigail

p5pRT commented 15 years ago

From @nwc10

On Tue\, Oct 27\, 2009 at 07:27:01AM -0400\, David Golden wrote:

I might be in favor of refaddr() moving into core from Scalar::Util so it's always available even if module loading is borked.

If "your" module loading is borked\, we don't support "you".

Nicholas Clark

p5pRT commented 15 years ago

From @xdg

On Tue\, Oct 27\, 2009 at 7:35 AM\, Nicholas Clark \nick@ccl4\.org wrote:

On Tue\, Oct 27\, 2009 at 07:27:01AM -0400\, David Golden wrote:

I might be in favor of refaddr() moving into core from Scalar::Util so it's always available even if module loading is borked.

If "your" module loading is borked\, we don't support "you".

Module loading in general. Otherwise\, 'use Scalar::Util qw/refaddr/'. The question is whether refaddr is something that really *must* be there when @INC is wrong/empty or the dirs are missing/renamed. Seems a bit esoteric to me\, but if someone insists that something replace reference stringification...

-- David

p5pRT commented 15 years ago

From @greerga

On Tue\, 27 Oct 2009\, Aristotle Pagaltzis wrote:

* goldstei@ugcs.caltech.edu (via RT) \perlbug\-followup@perl\.org [2009-10-27 09:35]:

I'm taking bets on if they think this is a bug or not.

My vote is with no.

Only in semantic nitpicking in that it works as designed.

As far as I’m concerned that design is indeed broken\, though.

Along similar lines I’d also like to eventualy see it become a fatal error to stringify a reference implicitly\, since that often happens by accident and the resulting string is useless in most circumstances\, but the silent apparent success of the operation leads to errors only turning up far away from where the stringification (ie. the real mistake) actually happened.

I don’t know how popular this opinion is\, though.

I'd perhaps use it as a "no stringify;" (like "no indirect;") but rolling it into "use strict;" itself by default doesn't tip the scales for me in cost/benefit.

My favorite stringy-oops has been doing tr// on a list of mixed strings/refs\, but that gets tracked down pretty quickly.

-- George Greer

p5pRT commented 15 years ago

From @ap

* George Greer \perl@greerga\.m\-l\.org [2009-10-27 13:15]:

I'd perhaps use it as a "no stringify;" (like "no indirect;")

A better name might be something like `no refconv;` (which would include preventing numeric operations on numified references).

My favorite stringy-oops has been doing tr// on a list of mixed strings/refs\, but that gets tracked down pretty quickly.

When working with non-trivially nested data it’s not uncommon to get a `Can't use string ("HASH(0xdeadbeef)") as a FOO ref` somewhere\, or absurd numbers when you’re calculating some kind of aggregate\, because you accidentally accessed the wrong element and numified a ref instead of accessing the right scalar\, or tried to deref a scalar instead of accessing the ref you wanted.

And it’s always real tedious to track down where the actual mistake is in such cases\, even when it doesn’t ultimately take much time. You usually have to try to trace logic that winds through recursive calls or nested loops\, which is a chore whether you debug with the debugger or with print statements.

It would be much less painful if you could at least optionally enable a fatal error for implicit ref conversions\, for debugging purposes. That would immediately tell you the “where” half of the problem\, instead of leaving you to painstakingly hunt for it. Throw a Carp::Always in there and you probably have most of the data you need to figure out the “why”.

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 15 years ago

From @ap

* Abigail \abigail@abigail\.be [2009-10-27 12:30]:

On Tue\, Oct 27\, 2009 at 07:21:45AM -0400\, David Golden wrote:

It should at least warn. But I actually think it should be fatal under strictures -- that's the whole point of strictures.

Really? Should strict also forbid using a string as a number? Or a float as a integer? A string as a regular expression?

What does that have to do with anything? We’re talking about implicit conversions of references\, not about any of these other cases.

I consider 'auto casting' a *feature* of Perl. One I use on a regular basis. I don't think Perl should start warning on one of its nicest features.

Argument from slippery slope. Please stick to the topic.

* Abigail \abigail@abigail\.be [2009-10-27 12:25]:

I use often stringified references. Either by printing them (debugging tool)\, or as hash keys. If I want a quick and dirty implementation of inside out objects and I'm using a pre-5.10 perl\, I use objects as keys keys directly.

That’s great.

If you want implicit ref conversions\, you don’t have to turn on the (hypothetical) feature that makes them a fatal error.

I sometimes turn off strictures too. Not often\, but it happens. Isn’t that also great?

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 15 years ago

From @abigail

On Tue\, Oct 27\, 2009 at 01:45:18PM +0100\, Aristotle Pagaltzis wrote:

It would be much less painful if you could at least optionally enable a fatal error for implicit ref conversions\, for debugging purposes.

That's easy\, no additional support needed:

{ package UNIVERSAL; use overload '""' => sub {die}; use overload '0+' => sub {die}; ... }

Abigail

p5pRT commented 15 years ago

From @ap

* Abigail \abigail@abigail\.be [2009-10-27 13:57]:

On Tue\, Oct 27\, 2009 at 01:45:18PM +0100\, Aristotle Pagaltzis wrote:

It would be much less painful if you could at least optionally enable a fatal error for implicit ref conversions\, for debugging purposes.

That's easy\, no additional support needed:
\{
    package UNIVERSAL;
    use overload '""' => sub \{die\};
    use overload '0\+' => sub \{die\};
    \.\.\.
\}

$ perl -E'{package UNIVERSAL; use overload q[""] => sub {die}\, "0+" => sub{die}} say \$_' SCALAR(0x8082cd8)

No cigar.

Aside from that: do you have a trick up your sleeve for how to scope UNIVERSAL monkeypatches lexically?

-- *AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2\,("\,$\/"\," ")[defined wantarray]/e;$1} &Just->another->Perl->hack; #Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 15 years ago

From @rjbs

* Aristotle Pagaltzis \pagaltzis@gmx\.de [2009-10-27T08:45:18]

* George Greer \perl@greerga\.m\-l\.org [2009-10-27 13:15]:

I'd perhaps use it as a "no stringify;" (like "no indirect;")

A better name might be something like `no refconv;` (which would include preventing numeric operations on numified references).

I believe\, but have not Googled\, that MJD proposed this some time ago as C\< no strict 'deref' >.

-- rjbs

p5pRT commented 15 years ago

From @davidnicol

On Tue\, Oct 27\, 2009 at 8:02 AM\, Aristotle Pagaltzis \pagaltzis@gmx\.de wrote:

Aside from that: do you have a trick up your sleeve for how to scope UNIVERSAL monkeypatches lexically?

Given an alternate universe where all Perl types are "Magic" and look up all of their operations in a per-type table (perhaps a Perl that uses Parrot Magic Cookies\, if they still exist -- this is quite a stale rant I'm dusting off here) it might be possible to lexically or locally (lexically == do something with compile time effects within a block; locally == do something with run-time effects and simultaneously schedule the un-doing of that something at block exit time)

Closer to reality\, if plain data was treated more like overloaded objects\, such tricks would become more possible. Although LEXICALLY rather than LOCALLY would be tricky\, the compilation phase would need to catch the possibility or compile to an ops including the alternate case either as something to check for and catch or as the handler in the table.

Moving stuff from late-bound to earlier-bound is certain to have some kind of very subtle effect by breaking things that use late binding\, which as a class of things are themselves tricky. Extra points will be awarded for restating that using even more words.

p5pRT commented 15 years ago

From @rgarcia

2009/10/27 Ricardo Signes \perl\.p5p@rjbs\.manxome\.org:

* Aristotle Pagaltzis \pagaltzis@gmx\.de [2009-10-27T08:45:18]

* George Greer \perl@greerga\.m\-l\.org [2009-10-27 13:15]:

I'd perhaps use it as a "no stringify;" (like "no indirect;")

A better name might be something like `no refconv;` (which would include preventing numeric operations on numified references).

I believe\, but have not Googled\, that MJD proposed this some time ago as C\< no strict 'deref' >.

No\, he proposed it as C\<use strict 'refs'> : http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00924.html and suggested making an exception for hash keys.

I think that it should be added in a new pragma.

If we add a new strict subpragma\, like C\<use strict "stringificationofrefs">\, we'll have problems\, because people will want to disable it locally by doing C\<use strict; no strict "stringificationofrefs">\, and that would be a fatal error on earlier perls.

If we add it directly in strict-refs\, we loose some granularity. Also that would make C\ more strict that it used to be -- that's not the 1st time that would happen\, but strictures were in the past only made strictier by little steps.

p5pRT commented 15 years ago

From @demerphq

2009/10/27 Rafael Garcia-Suarez \rgs@consttype\.org:

2009/10/27 Ricardo Signes \perl\.p5p@rjbs\.manxome\.org:

* Aristotle Pagaltzis \pagaltzis@gmx\.de [2009-10-27T08:45:18]

* George Greer \perl@greerga\.m\-l\.org [2009-10-27 13:15]:

I'd perhaps use it as a "no stringify;" (like "no indirect;")

A better name might be something like `no refconv;` (which would include preventing numeric operations on numified references).

I believe\, but have not Googled\, that MJD proposed this some time ago as C\< no strict 'deref' >.

No\, he proposed it as C\<use strict 'refs'> : http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00924.html and suggested making an exception for hash keys.

I think that it should be added in a new pragma.

If we add a new strict subpragma\, like C\<use strict "stringificationofrefs">\, we'll have problems\, because people will want to disable it locally by doing C\<use strict; no strict "stringificationofrefs">\, and that would be a fatal error on earlier perls.

Have we fixed this is new perls?

That is made no strict/no warnings future portable?

If not\, perhaps we should?

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT commented 15 years ago

From @abigail

On Tue\, Oct 27\, 2009 at 02:40:30PM +0100\, Rafael Garcia-Suarez wrote:

2009/10/27 Ricardo Signes \perl\.p5p@rjbs\.manxome\.org:

* Aristotle Pagaltzis \pagaltzis@gmx\.de [2009-10-27T08:45:18]

* George Greer \perl@greerga\.m\-l\.org [2009-10-27 13:15]:

I'd perhaps use it as a "no stringify;" (like "no indirect;")

A better name might be something like `no refconv;` (which would include preventing numeric operations on numified references).

I believe\, but have not Googled\, that MJD proposed this some time ago as C\< no strict 'deref' >.

No\, he proposed it as C\<use strict 'refs'> : http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00924.html and suggested making an exception for hash keys.

I think that it should be added in a new pragma.

If we add a new strict subpragma\, like C\<use strict "stringificationofrefs">\, we'll have problems\, because people will want to disable it locally by doing C\<use strict; no strict "stringificationofrefs">\, and that would be a fatal error on earlier perls.

I would prefer a new pragma as well\, but I don't really understand your argument. After all\, if it's added in a new pragma\, people will write 'use newpragma'\, and that will fail on older perls as well\, won't it?

If we add it directly in strict-refs\, we loose some granularity. Also that would make C\ more strict that it used to be -- that's not the 1st time that would happen\, but strictures were in the past only made strictier by little steps.

I it were to be added to 'strict-refs' directly\, I would stop using strict refs in my code.

Abigail

p5pRT commented 15 years ago

From @rgarcia

2009/10/27 Abigail \abigail@abigail\.be:

If we add a new strict subpragma\, like C\<use strict "stringificationofrefs">\, we'll have problems\, because people will want to disable it locally by doing C\<use strict; no strict "stringificationofrefs">\, and that would be a fatal error on earlier perls.

I would prefer a new pragma as well\, but I don't really understand your argument. After all\, if it's added in a new pragma\, people will write 'use newpragma'\, and that will fail on older perls as well\, won't it?

Not exactly : to use a new pragma\, you have to modify your code\, and implicitly state you require perl >= 5.X. Your old code will run unmodified. But\, if we change the meaning of use strict\, and if that forces you to modify your code to cope with a new strict subpragma\, you make it dependent on perl >= 5.X without really needing to.

(I was assuming that C\ continues to enable all strict subpragmas)

p5pRT commented 15 years ago

From @pjcj

On Tue\, Oct 27\, 2009 at 02:40:30PM +0100\, Rafael Garcia-Suarez wrote:

If we add a new strict subpragma\, like C\<use strict "stringificationofrefs">\, we'll have problems\, because people will want to disable it locally by doing C\<use strict; no strict "stringificationofrefs">\, and that would be a fatal error on earlier perls.

If we add it directly in strict-refs\, we loose some granularity. Also that would make C\ more strict that it used to be -- that's not the 1st time that would happen\, but strictures were in the past only made strictier by little steps.

I seem to recall that the last time someone wanted a new stricture (FSVO last) there was general agreement that not all strictures had to be turned on by a plain "use strict". In that case\, those who want this stricture could C\<use strict "stringificationofrefs"> and those who don't could ignore it\, as also those using older versions. It would still fail on older perls\, of course\, just as using any new feature would. It could even be turned on by "use 5.12" or whatever it is that turns on the bells\, whistles\, belt and braces if we wanted to go that far.

This is a post about strict rather than stringification. I don't have a strong opinion about stringification though I suspect I find it useful more often than problematic.

-- Paul Johnson - paul@pjcj.net http://www.pjcj.net

p5pRT commented 15 years ago

From @ap

* Abigail \abigail@abigail\.be [2009-10-27 15:10]:

I it were to be added to 'strict-refs' directly\, I would stop using strict refs in my code.

I wouldn’t\, but I would strictly oppose conflating them. I can easily imagine good uses for

no refconv; no strict 'refs';

-- *AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2\,("\,$\/"\," ")[defined wantarray]/e;$1} &Just->another->Perl->hack; #Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 15 years ago

From john.imrie@vodafoneemail.co.uk

Aristotle Pagaltzis wrote:

It would be much less painful if you could at least optionally enable a fatal error for implicit ref conversions\, for debugging purposes. That would immediately tell you the “where” half of the problem\, instead of leaving you to painstakingly hunt for it. Throw a Carp::Always in there and you probably have most of the data you need to figure out the “why”.

Regards\,

In which case somthing like use warnings FATAL => qw(refconv); would be more appropriate.

______________________________________________
This email has been scanned by Netintelligence
http://www.netintelligence.com/email

p5pRT commented 15 years ago

From @leonerd

On Tue\, 27 Oct 2009 11:05:11 +0000 Nicholas Clark \nick@ccl4\.org wrote:

On Tue\, Oct 27\, 2009 at 07:00:07AM -0400\, David Golden wrote:

To me\, it seems consistent with the idea "use strict 'refs'" -- if strictures are on\, stringifying or numifying a reference should be a fatal error.

Which breaks existing code that uses strict\, and the idiom of using the stringification of references as hash keys.

How about a non-default stricture?

use strict qw( :default refstring );

-- Paul "LeoNerd" Evans

leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/

Perl / perl5