geoffleach has asked for the wisdom of the Perl Monks concerning the following question:

O Monks,

I'm working on Audio::TagLib which provides an interface to (C++) taglib. Suddenly UNIVERSAL::can no longer find a number of taglib functions that were previously visible. I would appreciate instruction on (or a pointer to) the algorithm used.

Many thanks.

Perl 12.3, Linux Fedora 14, gcc 4.5.1 20100924

Replies are listed 'Best First'.
Re: Workings of UNIVERSAL::can
by Anonymous Monk on Jul 05, 2011 at 00:18 UTC
      Not likely to be the problem as that's the source base I'm working on. Although it is true that that distribution does not have my problem.

      Just to be clear, I'm not alleging that UNIVERSAL::can is buggy. If I understand what's it algorithm is -- how it finds out what files it searches to determine if a script 'can', then I can figure out what I'm doing wrong.

      I hope that this clears things up.

        I hope that this clears things up.....

        It really doesn't :)

        Anyway, It just walks @ISA asking if it can, See UNIVERSAL, perlobj, perlboot

Re: Workings of UNIVERSAL::can
by Somni (Friar) on Jul 06, 2011 at 22:48 UTC

    The algorithm is a simple symbol table search in method resolution order.

    If the method is not in the symbol table (perhaps it's loaded with AUTOLOAD, or otherwise loaded after the ->can call) it won't be found. If it's loaded via AUTOLOAD, the module itself will need to overload can so it can answer effectively for those functions; this is somewhat tricky to get right, as you need to allow the search to continue further up the tree as necessary.

    You mentioned later that ->can is not seeing your C++ functions. Unless these are exposed to the Perl level, they won't be in the symbol table; but then again, you shouldn't be able to call them from Perl, either, so finding them with ->can is simply wrong. If this is the case, you'll need to elaborate more as to what's going on.

      The algorithm is a simple symbol table search in method resolution order.

      Hi :D

      Actually :) Method resolution order is not an algorithm (or an actual order) or any more than symbol table search is an algorithm.

      Or put another way, a sort-algorithm is not an actual algorithm, but a bubble-sort-algorithm is an sort-algorithm; is an algorithm.

      Perl's default method-resolution-order, algorithm , is a linear-depth-first-search.

      You can change that in modern perls with the mro pragma to C3 linearization

        The fact that mro is changeable is why I said method resolution order, and not a specific order.

        Taken individually, each of the items is not an algorithm. Taken together (symbol table search in method resolution order), it is an algorithm, though ill-specified due to the variable of which mro is in effect.