| Subject: | Empty subroutine prototypes |
| Date: | Fri, 20 Oct 2006 09:58:25 -0600 |
| To: | via RT <bug-POE-Filter-XML [...] rt.cpan.org> |
| From: | Eric Waters <ewaters [...] uarc.com> |
Before I report another bug I'd like to say that I appreciate the work you've done on this software. I use this and a heavily modified POE::Component::Jabber (I'll show you the modifications at a later date) in an app I've been working on for the last few months.
This bug applies to almost all the code you write. It appears that a style decision that you made (probably a long time ago) now causes compile-time errors in Perl v5.8.8 (and earlier versions, not sure how far back).
It's also possible that this is a deliberate choice of yours.
The problem is that every subroutine you write has an empty prototype:
sub get_id()
{
my $self = shift;
return $self->[+id];
}
Normally this isn't an issue, as you call your subroutines as methods ($node->get_id()), and according to perlsub, method calls are not influenced by prototypes. But if you called it as a subroutine (so prototypes can be checked at compile time), you'd get a compiletime error:
#!/usr/bin/perl
use strict;
use warnings;
sub increment()
{
my $x = shift;
return $x + 1;
}
my $number = increment(5);
print "Have number $number\n";
Results in:
Too many arguments for main::increment at ./prototype_test.pl line 13, near "5)"
Execution of ./prototype_test.pl aborted due to compilation errors.
If the only way you ever called these subroutines was as class methods, then this would never come up (the empty prototype would never be evaluated). You seem to have avoided this in the example of POE::Filter::XML::Node.pm by declaring data() (which calls _encode() and _decode()) before _encode() and _decode() (since the subroutines occur after their usage, they can't be checked at compile time), this means that no function below _decode() can use _decode($value) as such would result in compile time error.
Maybe this was all deliberate. This could be a means to enforce privitization of class methods from public usage (POE::Filter::XML::Node::_encode($data) can never succeed), but it feels very klunky. Seems like other Perl techniques would be better suited for private class methods.
Nevertheless, in my opinion it is a flaw in the code that's trival to fix and would make the code more usable.
Eric
Message body not shown because it is not plain text.