Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Detecting sub/call mismatches?

Reply
Thread Tools

Detecting sub/call mismatches?

 
 
Tim McDaniel
Guest
Posts: n/a
 
      11-21-2012
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, http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
C.DeRykus
Guest
Posts: n/a
 
      11-21-2012
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
 
Reply With Quote
 
 
 
 
Tim McDaniel
Guest
Posts: n/a
 
      11-21-2012
In article <(E-Mail Removed)>,
>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, (E-Mail Removed)
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      11-21-2012
(E-Mail Removed) (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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Detecting end of file for VHDL'93 Gary Thorpe VHDL 2 07-12-2005 07:42 AM
Detecting if Mozilla is Running Peter Firefox 1 04-30-2005 09:47 PM
Detecting edge in a clock synchronous porcess Praveen VHDL 2 04-12-2005 11:36 AM
Detecting of 'U' in a std_logic_vector Thomas Reinemann VHDL 4 11-03-2004 08:24 AM
detecting if program is running under X windows or not Paul Faulstich Perl 1 01-10-2004 07:16 PM



Advertisments