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<keys>, C<values> and C<each>,
it was mistakenly added to C<push>, C<pop>, C<shift>, C<unshift> and
C<splice> too.

- Eric

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

From @ikegami

On Tue, Jul 12, 2011 at 1​:52 PM, Eric Brine <perlbug-followup@​perl.org>wrote​:

# 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<keys>, C<values> and C<each>,
it was mistakenly added to C<push>, C<pop>, C<shift>, C<unshift> and
C<splice> too.

- Eric

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

From @xdg

On Tue, Jul 12, 2011 at 2​:12 PM, Eric Brine <ikegami@​adaelis.com> wrote​:

It appears that when the check was added to C<keys>, C<values> and C<each>,
it was mistakenly added to C<push>, C<pop>, C<shift>, C<unshift> and
C<splice> too.

- Eric

Just to be clear, the bug is that C<push> 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

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

From @ikegami

On Tue, Jul 12, 2011 at 2​:28 PM, David Golden <xdaveg@​gmail.com> wrote​:

On Tue, Jul 12, 2011 at 2​:12 PM, Eric Brine <ikegami@​adaelis.com> wrote​:

It appears that when the check was added to C<keys>, C<values> and
C<each>,
it was mistakenly added to C<push>, C<pop>, C<shift>, C<unshift> and
C<splice> too.

- Eric

Just to be clear, the bug is that C<push> 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?

From @xdg

On Tue, Jul 12, 2011 at 2​:43 PM, Eric Brine <ikegami@​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

From @sciurius

David Golden <xdaveg@​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

From @jbenjore

On Tue, Jul 12, 2011 at 12​:19 PM, Johan Vromans <jvromans@​squirrel.nl> wrote​:

David Golden <xdaveg@​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

From @sciurius

Joshua ben Jore <twists@​gmail.com> writes​:

On Tue, Jul 12, 2011 at 12​:19 PM, Johan Vromans <jvromans@​squirrel.nl> wrote​:

David Golden <xdaveg@​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

From @jandubois

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

Joshua ben Jore <twists@​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

From @ikegami

On Tue, Jul 12, 2011 at 2​:46 PM, David Golden <xdaveg@​gmail.com> wrote​:

On Tue, Jul 12, 2011 at 2​:43 PM, Eric Brine <ikegami@​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<push> works with some arrays "views" (magic) but not always with
  others (overloaded @​{})

- Eric

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

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