Please fracking make this go away.t/storage_validate_data...................Called UNIVERSAL::can() as a function, not a method at C:/strawberry-perl/perl/site
/lib/DateTime/Locale.pm line 313
I don't care who's fault it is, but it isn't mine. Now stop pissing in my pool just because I'm mock testing and UNIVERSAL::JAMMYRELIGIONINYOURFACE is loaded.
That is all.
/rant mode=off
Re:What that is...
chromatic on 2007-11-01T04:30:02
All too true, but given the lack of willingness of some CPAN authors to fix bugs in their modules, I plan to release new versions of UNIVERSAL::isa and UNIVERSAL::can which only give those warnings for code that calls them for modules which use both modules directly.
I should have time to work on that this weekend.
Re:What that is...
autarch on 2007-11-01T05:05:02
Err, take a look at that line:What exactly is wrong with that?unless ( $real_class->can('new') )Re:What that is...
chromatic on 2007-11-01T05:29:37
If you can trigger that false positive in a test case, I'll add it to the U::c/U::i suite and fix it.
Re:What that is...
jrockway on 2007-11-01T15:02:25
A shot in the dark, but is $real_class loaded when you make that call?
Compare:
$ foo->isa('UNIVERSAL') and print "yes\n"
<nothing>
to
$ package foo;
$ foo->isa('UNIVERSAL') and print "yes\n"
yes
I think U::can might get upset in this case... but who knows.
Another possibility... didn't that line use can as a function in an older version of the module? I can't get the warning to happen with the latest DateTime::Locale, but I could about a year ago.Re:What that is...
jrockway on 2007-11-01T15:06:04
Sorry, an addendum:
$ use UNIVERSAL::can;
$ UNIVERSAL->can('can') and print "can can\n";
can can
$ FOOBAR->can('can') or print "cannot can\n";
Called UNIVERSAL::can() as a function, not a method at (eval 59) line 5
cannot can
$ package FOOBAR;
$ FOOBAR->can('can') and print "now can can\n";
now can can
Re:What that is...
autarch on 2007-11-01T15:26:34
Yep, that's the issue. In fact, the use ofcanis a way to check if the module has been loaded. It's quicker than blindly usingrequirein every case, I think.Re:What that is...
chromatic on 2007-11-01T17:31:05
That's the problem then. Your heuristic for testing if a class exists fights with my heuristic for testing if a class exists. I suppose U::i/U::c could skim through the optree for a
methodormethod_namedopcode, but that's a lot more work.Re:What that is...
autarch on 2007-11-01T20:03:44
Well, I think the problem is yours, since clearly I'm using UNIVERSAL::can as a method there, not a function, but your module is reporting that I'm using it as a function anyway.
Re:What that is...
btilly on 2007-11-02T02:38:41
I cannot reproduce the behavior on perl 5.8.6. But based on the description, there is a simpler solution. See whether the package can was called for is in the package tree. If it is not, then don't warn.
In fact you already have the necessary logic in UNIVERSAL::can to figure out whether the package is in the symbol table. Therefore the following patch looks like it should fix the problem:
---/usr/lib/perl5/site_perl/5.8.6/UNIVERSAL/can.pm 2006-03-31 22:15:10.000000000 -0800
+++ can.pm 2007-11-01 19:28:29.000000000 -0700
@@ -51,7 +51,6 @@
# make sure the invocant is useful
unless ( _is_invocant( $_[0] ) )
{
- _report_warning();
goto &$orig;
}Re:What that is...
btilly on 2007-11-02T14:08:14
D'oh. Just use warnings and I can reproduce the behaviour. And yes, my patch fixed it.That smells like a really bad idea
btilly on 2007-11-02T14:06:04
You are relying on undocumented internal behaviour. At the very least I can find no documentation that a class that has not been fully defined yet does not have the methods that all classes should have. In fact I would prefer it if Perl had the opposite behaviour. What will you do if that behaviour changes someday?
Furthermore pity the poor programmer who has to figure out your code. Do you always put comments on your uses of that idiom? If not, then will it make sense to someone else that you're checking whether something can can when it should always be able to can? It wouldn't to me!
It is far safer to write a function to do your test. That function can either check %INC directly or can walk the symbol table. (Walking the symbol table is closer to what calling the can method is.) Then you can just write is_loaded("class") and your code is more self-documenting, and is less likely to break in a future version of Perl.Re:That smells like a really bad idea
btilly on 2007-11-02T14:10:16
D'oh! You aren't relying on undocumented internal behaviour. You're checking for whether the class can call new, not whether it can call can!
I'll just go hide in a corner then.Re:What that is...
jk2addict on 2007-11-01T15:19:13
I had the same thought, so I updated my DateTime/DateTime::Locale to the latest before my rant...on my strawberry perl install and on my Ubuntu/OSX installs which are quite recent.Re:What that is...
jk2addict on 2007-11-01T13:05:49
Which it does [as a method] according to the code. And let me be clear, this isn't/wasn't meant as a personal attack on the module authors directly. It's just that I've stared at that warning for two years worth of Handel tests, and I finally cracked.:-) UTS, L
grinder on 2007-11-01T16:57:04
Heh, we had the same long-time issues on a local box, and as we deemed it to be SEP, we commented out the warning message. The world has come to an end, so far
:) Re:UTS, L
grinder on 2007-11-01T16:59:23
err, not come to an end, of course. (jeez I wish this software would let us edit comments -- that's the second time in a week).
