Is there a problem in perl 5.12.2 using splice on @ISA?

Question

The following is a debug session on Perl 5.12. Does this make any sense? Does UNIVERSAL cache a version of the @ISA variable, which if forever uses thereafer. Back before Class::ISA was deprecated, I used to call Class::ISA::self_and_super_path to get the internals to relook at the @ISA array. Since it is now considered unnecessary, how do you get perl to audit its internal records?

DB<34> p $papa
Papushka=HASH(0x16bc0300)

DB<35> p $papa->isa('Nanushka')

DB<36> p $papa->isa('Babushka')
1

DB<37> x @Papushka::ISA
0  'Nanushka'
1  'Babushka'

This is test code (obviously). It's getting the same results, run flat, run as a test, or run in debug. I should tell you that prior to this @ISA = qw<Babushka> and I performed

splice( @ISA, 0, 0, 'Nanushka' );

Is that the problem? Should you only ever push onto @ISA?

Answer 1

The replacement for Class::ISA::self_and_super_path is mro::get_linear_isa. That's available either from mro itself, or, if you want to support old perls, via MRO::Compat.

Also, @ISA is a magic variable.

$ perl -MDevel::Peek -e'Dump \@ISA'
SV = IV(0x1b92e20) at 0x1b92e28
  REFCNT = 1
  FLAGS = (TEMP,ROK)
  RV = 0x1bbcd58
  SV = PVAV(0x1b93cf8) at 0x1bbcd58
    REFCNT = 2
    FLAGS = (SMG,RMG)
    MAGIC = 0x1bc0f68
      MG_VIRTUAL = &PL_vtbl_isa
      MG_TYPE = PERL_MAGIC_isa(I)
      MG_OBJ = 0x1bbcd40
    ARRAY = 0x0
    FILL = -1
    MAX = -1
    ARYLEN = 0x0
    FLAGS = (REAL)

Note the PERL_MAGIC_isa. That's what drives this particular mechanism.

Whenever it is changed, the contents of any caches that rely on its value are supposed to be updated.

$ perl -E'say Foo->isa(q[Bar]) || 0; @Foo::ISA = qw(Bar Baz); say Foo->isa(q[Bar]) || 0'
0
1

Apparently you've found a case where the cache invalidation doesn't happen. I consider this a bug. Chances are splice, for some reason, doesn't invoke the isa magic appropriately. You could try to modify @ISA in an alternative way, for example using unshift or an assignment, or possibly try mro::method_changed_in, which would invalidate the method resolution caches, which are bound to the various @ISAs.

If you could reduce this bug to a minimal testcase, that'd be hugely helpful in getting this bug fixed.

Update:

A minimal testcase turned out to be easy:

$ perl -E'say Foo->isa(q[Bar]) || 0; splice @Foo::ISA, 0, 0, q[Bar]; say Foo->isa(q[Bar]) || 0'
0
0

This is caused by pp_splice not doing something like mg_set((SV *)ary). push, unshift, and regular assignments do that correctly, so using one of these should fix your issue.

Another Update:

This change, which I just committed to perl, fixes the issue. However, as the odd behaviour of splice not invoking magic is already present in 5.8 and 5.10, it's not a regression and therefore not going to be part of 5.12.3 in a few months. 5.13.6, which will be released next week, and 5.14.0, next northern spring, will probably have it.

Answer 2

Yes, there is a cache. But if you can modify @ISA without invalidating that cache, I would consider it a bug in perl.

Does your problem disappear if you add the line @ISA = @ISA; after your splice line?