Error saying an overridden method in a subclass is redefined

[livefree75]

I have a small "abstract" class and a number of implementing subclasses. They're all very small and I don't want to make separate files for each one, using the folder structure recommended by CPAN.

use strict;
use warnings;

package EWCC::Foo;

sub new {
    my $class = shift;
    bless {}, $class;
}

package EWCC::Foo::Bar;

use base 'EWCC::Foo';

sub new {
    my $class = shift;
    my $self  = $class->SUPER::new(@_);
    return $self;
}

1;

The file is in a folder called "EWCC" and the file is "Foo.pm".
PerlNavigator is giving me a yellow squiggly line on the use strict and another on the second new function, saying that "new" has been redefined. But they're clearly in different packages. Yes it's redefined; EWCC::Foo::Bar::new overrides EWCC::Foo::new, and that's perfectly legal. Compiles and runs fine.

Note that this only happens if the base class has a prefix, in this case EWCC::. If I just use Foo and Foo::Bar, I don't get the yellow squiggles. It also doesn't happen if the base class name doesn't match the filename. e.g., if I change the filename to "Fee.pm", the yellow squiggles go away.

Is this a bug or a feature? :)

[bscan]

Hi @livefree75, this is a tricky one, but I am unable to reproduce. This was a problem in the Perl Navigator prior to version 0.3.1 in mid-2022, but should no longer be a problem assuming you don't have an ancient version. There are some other common Perl extensions that still suffer from this specific issue if you could check what else you have installed or provide a screenshot showing the error.

I'll provide some context on the underlying issue though. You can also reproduce it by running perl -c EWCC/Foo.pm. This results in Perl reloading the file itself when the use base 'EWCC::Foo'; line is encountered. It's worse when running an extension as "Foo.pm" is generally compiled in memory (because you may have unsaved changes), so it would load the underlying Foo.pm file when hitting that line. In addition to showing functions as being redefined (one version in memory, one version on disk), it is also painful to debug. The same issue previously occurred when two .pm files referenced each other, resulting in a circular dependency.

You can also fix this by changing:

use base 'EWCC::Foo';

to:

use parent -norequire, 'EWCC::Foo';

Given that your content is all in the same file, you don't need the subclass to go looking for the parent file module. The docs in https://perldoc.perl.org/base also clarify some of the other issues you are seeing regarding naming. When "base" is unable to find the parent module, it will not die or issue any warnings, nor will it be able to find a second copy of the functions.

Anyway, all of this should've been resolved by this issue: #20 . Let me know what you find in terms of version numbers or a screenshot. It's certainly possible there's a bug in this logic and something different about our setups prevented me from reproducing the issue.

[livefree75]

Well I guess I should ask, is it bad practice to do this? Should I really be following the convention of one package per file? Sometimes it seems tedious because my class may be just a tiny subclass of the main one, or vice versa. The main might be just a tiny abstract class. Jamie

…

On Mon, Jan 20, 2025, 2:26 PM bscan ***@***.***> wrote: Hi @livefree75 <https://github.com/livefree75>, this is a tricky one, but I am unable to reproduce. This was a problem in the Perl Navigator prior to version 0.3.1 in mid-2022, but should no longer be a problem assuming you don't have an ancient version. There are some other common Perl extensions that still suffer from this specific issue if you could check what else you have installed or provide a screenshot showing the error. I'll provide some context on the underlying issue though. You can also reproduce it by running perl -c EWCC/Foo.pm. This results in Perl reloading the file itself when the use base 'EWCC::Foo'; line is encountered. It's worse when running an extension as "Foo.pm" is generally compiled in memory (because you may have unsaved changes), so it would load the underlying Foo.pm file when hitting that line. In addition to showing functions as being redefined (one version in memory, one version on disk), it is also painful to debug. The same issue previously occurred when two .pm files referenced each other, resulting in a circular dependency. Anyway, all of this should've been resolved by this issue: #20 <#20> . Let me know what you find in terms of version numbers or a screenshot. It's certainly possible there's a bug in this logic and something different about our setups prevented me from reproducing the issue. — Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKF63E5RFPCZF4GRRFH2UL2LVEWFAVCNFSM6AAAAABUX7PJPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBTGEYTKNBSGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>