Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'd say that as well as providing an Object-Oriented interface, for some strange reason, Foo.pm is also exporting a function called Foo() you can use directly.

    Which is stupid of course, since now when doing OO you have to say

        Foo::->new;

    The subroutine is found before the word is treating as a string (and thus class) and so Foo() returns undef, which gives your error.

    I seem to recall encountering this during my AppSpace days a few times, with the end result I wrote a standard symbol table scanning unit test that would fail if it ever saw that specific subroutine/class clash.

    I think the code might even be in Test::ClassAPI still, since that was spun out of that code...
    • No. If Foo.pm exports a sub Foo, there's no problem.
      • Sorry?

        The specific problem is function vs class name. Why does it matter where the subroutine comes from?

        Specifically, if Foo contains sub Foo::Foo { undef } and exports it, what differs it from my defining sub Foo { undef } by hand?

        What am I missing here? Something different about the *Foo glob?

        Adam K