search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.94k stars 554 forks source link

push doesn't work on blessed references #11498

Closed p5pRT closed 8 years ago

p5pRT commented 13 years ago

Migrated from rt.perl.org#94654 (status was 'rejected')

Searchable as RT94654$

p5pRT commented 13 years ago

From @ikegami

Created by @ikegami

$ perl -wE'$_ = bless([]); push $_\, "a";' Not an unblessed ARRAY reference at -e line 1.

It appears that when the check was added to C\\, C\ and C\\, it was mistakenly added to C\\, C\\, C\\, C\ and C\ too.

- Eric

Perl Info ``` Flags: category=core severity=low Site configuration information for perl 5.14.0: Configured by eric at Fri Jun 10 15:56:22 EDT 2011. Summary of my perl5 (revision 5 version 14 subversion 0) configuration: Platform: osname=linux, osvers=2.6.32-5-686, archname=i686-linux-thread-multi uname='linux fmdev10 2.6.32-5-686 #1 smp tue mar 8 21:36:00 utc 2011 i686 gnulinux ' config_args='-de -Dprefix=/home/eric/usr/perlbrew/perls/perl-5.14.0t -Dusethreads' 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 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.4.5', 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 =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib /lib64 /usr/lib64 libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.11.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.11.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector' Locally applied patches: @INC for perl 5.14.0: /home/eric/usr/perlbrew/perls/perl-5.14.0t/lib/site_perl/5.14.0/i686-linux-thread-multi /home/eric/usr/perlbrew/perls/perl-5.14.0t/lib/site_perl/5.14.0 /home/eric/usr/perlbrew/perls/perl-5.14.0t/lib/5.14.0/i686-linux-thread-multi /home/eric/usr/perlbrew/perls/perl-5.14.0t/lib/5.14.0 . Environment for perl 5.14.0: HOME=/home/eric LANG=en_US.UTF-8 LANGUAGE= LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/eric/usr/perlbrew/bin:/home/eric/usr/perlbrew/perls/perl-5.14.0t/bin:.:/home/eric/bin:/usr/local/bin:/usr/bin:/bin:/usr/games PERLBREW_HOME=/home/eric/.perlbrew PERLBREW_PATH=/home/eric/usr/perlbrew/bin:/home/eric/usr/perlbrew/perls/perl-5.14.0t/bin PERLBREW_PERL=perl-5.14.0t PERLBREW_ROOT=/home/eric/usr/perlbrew PERLBREW_VERSION=0.25 PERL_BADLANG (unset) SHELL=/bin/bash ```
p5pRT commented 13 years ago

From @ikegami

On Tue\, Jul 12\, 2011 at 1​:52 PM\, Eric Brine \perlbug\-followup@​perl\.orgwrote​:

# New Ticket Created by "Eric Brine" # Please include the string​: [perl #94654] # in the subject line of all future correspondence about this issue. # \<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=94654 >

This is a bug report for perl from ikegami@​adaelis.com\, generated with the help of perlbug 1.39 running under perl 5.14.0.

----------------------------------------------------------------- [Please describe your issue here]

$ perl -wE'$_ = bless([]); push $_\, "a";' Not an unblessed ARRAY reference at -e line 1.

It appears that when the check was added to C\\, C\ and C\\, it was mistakenly added to C\\, C\\, C\\, C\ and C\ too.

- Eric

Just to be clear\, the bug is that C\ works on some arrays but not others (e.g. blessed array\, blessed hash with overloaded @​{}) . This limitation is neither documented nor required.

p5pRT commented 13 years ago

From @xdg

On Tue\, Jul 12\, 2011 at 2​:12 PM\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

It appears that when the check was added to C\\, C\ and C\\, it was mistakenly added to C\\, C\\, C\\, C\ and C\ too.

- Eric

Just to be clear\, the bug is that C\ works on some arrays but not others (e.g. blessed array\, blessed hash with overloaded @​{}) . This limitation is neither documented nor required.

In RT #80626\, the final decision was the automatic dereferencing should only happen on unblessed arrays/hashes for all of "the customary array and hash functions" (IIRC the phrase). While this is not strictly necessary for "push $array_object"\, the intent was to have consistency between push/pop/shift/unshift/splice and keys/value/each rather than have array objects work on the first set and fail on the second set.

The documentation should be amended to reflect this limitation.

-- David

p5pRT commented 13 years ago

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

p5pRT commented 13 years ago

From @ikegami

On Tue\, Jul 12\, 2011 at 2​:28 PM\, David Golden \xdaveg@&#8203;gmail\.com wrote​:

On Tue\, Jul 12\, 2011 at 2​:12 PM\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

It appears that when the check was added to C\\, C\ and C\\, it was mistakenly added to C\\, C\\, C\\, C\ and C\ too.

- Eric

Just to be clear\, the bug is that C\ works on some arrays but not others (e.g. blessed array\, blessed hash with overloaded @​{}) . This limitation is neither documented nor required.

In RT #80626\, the final decision was the automatic dereferencing should only happen on unblessed arrays/hashes for all of "the customary array and hash functions"

I thought we were trying to get rid of the bugs resulting from choice of storage format. Why are we introducing new ones as work is being down to fix the Unicode Bug\, smart matching\, etc?

p5pRT commented 13 years ago

From @xdg

On Tue\, Jul 12\, 2011 at 2​:43 PM\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

I thought we were trying to get rid of the bugs resulting from choice of storage format. Why are we introducing new ones as work is being down to fix the Unicode Bug\, smart matching\, etc?

One argument is that objects are opaque and perl should not go around messing with their internals without an explicit dereference (of an appropriate type) supplied by the user. The same problem doesn't exist with unblessed references.

It could be made to work with array-only functions (push/pop/etc.) but is ambiguous for array-or-hash functions (keys/values/each). I think the idea in the end was that it's easier to teach if those two work similarly (i.e. only on unblessed references).

David

p5pRT commented 13 years ago

From @sciurius

David Golden \xdaveg@&#8203;gmail\.com writes​:

One argument is that objects are opaque and perl should not go around messing with their internals without an explicit dereference (of an appropriate type) supplied by the user. The same problem doesn't exist with unblessed references.

Okay\, but then​:

$ perl -wlE 'my $a = bless[]; push $a\, 1' Not an unblessed ARRAY reference at -e line 1.

There's no such thing as an "unblessed ARRAY reference". It's either an array reference or an object. So the message should read​: "Not an ARRAY reference".

-- Johan

p5pRT commented 13 years ago

From @jbenjore

On Tue\, Jul 12\, 2011 at 12​:19 PM\, Johan Vromans \jvromans@&#8203;squirrel\.nl wrote​:

David Golden \xdaveg@&#8203;gmail\.com writes​:

One argument is that objects are opaque and perl should not go around messing with their internals without an explicit dereference (of an appropriate type) supplied by the user.  The same problem doesn't exist with unblessed references.

Okay\, but then​:

 $ perl -wlE 'my $a = bless[]; push $a\, 1'  Not an unblessed ARRAY reference at -e line 1.

There's no such thing as an "unblessed ARRAY reference". It's either an array reference or an object. So the message should read​: "Not an ARRAY reference".

That would be an inaccurate and misleading error message since the operand is clearly an array reference\, it is merely one we've singled out for unusual treatment.

Josh

p5pRT commented 13 years ago

From @sciurius

Joshua ben Jore \twists@&#8203;gmail\.com writes​:

On Tue\, Jul 12\, 2011 at 12​:19 PM\, Johan Vromans \jvromans@&#8203;squirrel\.nl wrote​:

David Golden \xdaveg@&#8203;gmail\.com writes​:

One argument is that objects are opaque and perl should not go around messing with their internals ...

There's no such thing as an "unblessed ARRAY reference". It's either an array reference or an object. So the message should read​: "Not an ARRAY reference".

That would be an inaccurate and misleading error message since the operand is clearly an array reference\,

Au contraire. If the statement is that objects are opaque\, then the array reference becomes an opaque object as soon as it is blessed. Refering to "unblessed array reference" implies there's also a "blessed array reference'. But by blessing an array reference it becomes an object.

-- Johan

p5pRT commented 13 years ago

From @jandubois

On Tue\, 12 Jul 2011\, Johan Vromans wrote​:

Joshua ben Jore \twists@&#8203;gmail\.com writes​:

That would be an inaccurate and misleading error message since the operand is clearly an array reference\,

Au contraire. If the statement is that objects are opaque\, then the array reference becomes an opaque object as soon as it is blessed. Refering to "unblessed array reference" implies there's also a "blessed array reference'. But by blessing an array reference it becomes an object.

While it does indeed become an object\, that doesn't mean it ceases to be an array reference at the same time. Otherwise it would be pretty useless because you wouldn't have anything to hang your instance data onto. This still works\, right​:

  push @​$self\, $whatever;

So it isn't unreasonable to expect this to work as well​:

  push $self\, $whatever;

Claiming that the later doesn't work because $self is not an array reference doesn't make any sense because then the former should have failed as well.

Cheers\, -Jan

p5pRT commented 13 years ago

From @ikegami

On Tue\, Jul 12\, 2011 at 2​:46 PM\, David Golden \xdaveg@&#8203;gmail\.com wrote​:

On Tue\, Jul 12\, 2011 at 2​:43 PM\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

I thought we were trying to get rid of the bugs resulting from choice of storage format. Why are we introducing new ones as work is being down to fix the Unicode Bug\, smart matching\, etc?

One argument is that objects are opaque and perl should not go around messing with their internals without an explicit dereference (of an appropriate type) supplied by the user. The same problem doesn't exist with unblessed references.

First\, it's not Perl doing the "messing"\, it's the caller\, and it may very well be fine for it to "mess".

sub enqueue {   my $queue = shift;   return if !@​_;   lock $queue;   push $queue\, @​_;   &cond_signal($queue); }

Second\, the point of forbidding this was for prevent confusion with objects with overloaded operators\, yet those intentionally return something that can be messed with here.

It could be made to work with array-only functions (push/pop/etc.) but

is ambiguous for array-or-hash functions (keys/values/each).

The bug report is just for the former.

I think the idea in the end was that it's easier to teach if those two work similarly (i.e. only on unblessed references).

It removes one inconsistency but adds two more​:

  - C\<push $a\, $_;> is not equivalent to C\<push @​$a\, $_;>

  - C\ works with some arrays "views" (magic) but not always with   others (overloaded @​{})

- Eric

p5pRT commented 8 years ago

From @cpansprout

This ticket can be closed (and I am closing it)\, because the auto-deref feature to which it pertains was removed in 5.24.

--

Father Chrysostomos

p5pRT commented 8 years ago

@cpansprout - Status changed from 'open' to 'rejected'