Detecting sub/call mismatches?
 

I'm moving subs from one source file to another, and sometimes
renaming them according to a more unified naming convention, so
OldModule::OldName
OldName (while in package OldModule)
should all be changed to NewModule::NewName.

The problem, of course, is when I screw up a call to some version of
the old name, which (so far) has ended up as
OldModule::OldName (that is, I overlooked it entirely)
OldModule::NewName
OldName (while in package OldModule; overlooked)
NewName (while in package OldModule, so that's OldModule::NewName)
I've caught these by eyeball inspection and I'll go thru it again, but
I'm nervous.

In Perl, of course, you can't in general do a static "compile time"
check -- in principle, there could be a sub defined with eval, a
reference to a sub, a sub name generated by code, et cetera.

Nevertheless, even if I can't get perfection, I'd like to do some
static verification if it's possible -- a Perl lint, for those
familiar with the old C tool. In practice, our code rarely does
obscure things. All I've seen are package declarations alone on a
line, and "sub SomeName *{" starting in column 1, and calls to
SomeModule:SomeName, except within SomeModule, where we usually do
just SomeName.

Is there anything I can do to get a partial check?

I've thought of hacking together a script that reads source files to
look for package and sub declarations to generate a table of potential
definitions, and the uses are every word that is followed by a left
paren. I could get some false results due to not following the proper
parsing (is there a module to parse Perl code?), like misunderstanding
quotation or comments. But even if I find one error now instead of
several weeks from now when some obscure path is finally run, and get
a slew of bad hits, I'd be happier.

--
Tim McDaniel, tmcd@panix.com

Re: Detecting sub/call mismatches?
 

On Tuesday, November 20, 2012 7:07:11 PM UTC-8, Tim McDaniel wrote:
> I'm moving subs from one source file to another, and sometimes
>
> renaming them according to a more unified naming convention, so
>
> OldModule::OldName
>
> OldName (while in package OldModule)
>
> should all be changed to NewModule::NewName.
>
>
>
> The problem, of course, is when I screw up a call to some version of
>
> the old name, which (so far) has ended up as
>
> OldModule::OldName (that is, I overlooked it entirely)
>
> OldModule::NewName
>
> OldName (while in package OldModule; overlooked)
>
> NewName (while in package OldModule, so that's OldModule::NewName)
>
> I've caught these by eyeball inspection and I'll go thru it again, but
>
> I'm nervous.
>
>
>
> In Perl, of course, you can't in general do a static "compile time"
>
> check -- in principle, there could be a sub defined with eval, a
>
> reference to a sub, a sub name generated by code, et cetera.
>
>
>
> Nevertheless, even if I can't get perfection, I'd like to do some
>
> static verification if it's possible -- a Perl lint, for those
>
> familiar with the old C tool. In practice, our code rarely does
>
> obscure things. All I've seen are package declarations alone on a
>
> line, and "sub SomeName *{" starting in column 1, and calls to
>
> SomeModule:SomeName, except within SomeModule, where we usually do
>
> just SomeName.
>
>
>
> Is there anything I can do to get a partial check?
>
>
>
> I've thought of hacking together a script that reads source files to
>
> look for package and sub declarations to generate a table of potential
>
> definitions, and the uses are every word that is followed by a left
>
> paren. I could get some false results due to not following the proper
>
> parsing (is there a module to parse Perl code?), like misunderstanding
>
> quotation or comments. But even if I find one error now instead of
>
> several weeks from now when some obscure path is finally run, and get
>
> a slew of bad hits, I'd be happier.
>
>

B::Xref might help - perldoc B::Xref

--
Charles DeRykus

Re: Detecting sub/call mismatches?
 

In article <43ad4a1e-1ff3-49c7-a07f-b31ea250e2ca@googlegroups.com>,
>B::Xref might help - perldoc B::Xref

Interesting -- thank you for the pointer.

It's strange, though, that /^File / lines are so odd:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~
File
Subroutine (definitions)
....

File ^E
Subroutine (definitions)
Package Moose::Error::Util
&_create_error_carpmess s26
&create_error s43
&create_error_confess s34
&create_error_croak s30
File<EB>}
Subroutine (definitions)
....

File
2Bh^W
Subroutine (definitions)
....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~


--
Tim McDaniel, tmcd@panix.com

Re: Detecting sub/call mismatches?
 

tmcd@panix.com (Tim McDaniel) writes:
> I'm moving subs from one source file to another, and sometimes
> renaming them according to a more unified naming convention, so
> OldModule::OldName
> OldName (while in package OldModule)
> should all be changed to NewModule::NewName.
>
> The problem, of course, is when I screw up a call to some version of
> the old name, which (so far) has ended up as
> OldModule::OldName (that is, I overlooked it entirely)
> OldModule::NewName
> OldName (while in package OldModule; overlooked)
> NewName (while in package OldModule, so that's OldModule::NewName)
> I've caught these by eyeball inspection and I'll go thru it again, but
> I'm nervous.
>
> In Perl, of course, you can't in general do a static "compile time"
> check -- in principle, there could be a sub defined with eval, a
> reference to a sub, a sub name generated by code, et cetera.
>
> Nevertheless, even if I can't get perfection, I'd like to do some
> static verification if it's possible -- a Perl lint, for those
> familiar with the old C tool.

You could try B::Lint.