Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
A coworker called me over on a problem he was completely stumped by. His boss was completely stumped by it, too. The problem looked like this:
use Foo;
my $foo = Foo->new;
Which resulted in the error Can't call method "new" on an undefined value.... I admit it had me stumped at first, but a quick session in the debugger and stepping through the code revealed the problem. Both 'strict' and 'warnings' were enabled, so the problem is not related to that.
No fair (Score:2)
I haven't gotten done guessing the last problem, yet!
Is the problem apparent from the code snippet you posted, alone?
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re: (Score:2)
The problem is caused by something else and that something else is not in Foo.pm. But once you realize what's going on, you'll slap your forehead and say "of course!"
__ (Score:1)
Re: (Score:2)
Yup. I was called over to look at the problem and it simply didn't occur to me that someone would name a sub after a package name.
Re: (Score:1)
Despite the fact that you are the author of aliased [cpan.org]?
Re: (Score:2)
With aliased, the sub is not the package name -- it's a shorter version -- and in any event, because it has a null prototype, it gets inlined away and no subroutine is left in the symbol table.
However, that's still a pretty lame defense on my part :)
Re: (Score:1)
Yeah, but it’s used like a package name, on the left side of an arrow operator.
Not at all. It gets inlined into calls, but the subroutine is always there.
Re: (Score:2)
Ref: http://dk.php.net/manual/en/language.oop.php [php.net]
If anybody wonders as to why somebody would do it in the first place...
Without reading the other comments... (Score:1)
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 sc
Re: (Score:1)
Re: (Score:1)
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