http://www.perlmonks.org?node_id=819533


in reply to Re: override prototype
in thread override prototype

I use a prototype because nimLog uses one. I was using ($$) prototype months ago when I first redefined the sub so I got no prototype warning.

I use nimLog because modules I use from the supplier use nimLog, when debugging I can get their logging in my logfile too (though not in my STDOUT debug stream).

Thanks for the pragma to fix the warning. I was thinking it was an error because something else in my code was causing it to die prematurely, doh!

I guess now I suppressed the warning anyway I can also remove the prototype completely.

Thanks for your help,
R.

Pereant, qui ante nos nostra dixerunt!

Replies are listed 'Best First'.
Re^3: override prototype
by ikegami (Patriarch) on Jan 25, 2010 at 17:27 UTC

    I use a prototype because nimLog uses one.

    And I'm asking why it has one.

    I use nimLog because modules I use from the supplier use nimLog

    I'm asking about the module where you replace nimLog with your own function, not some other module that wasn't even mentioned. Compare 

    # What you do
use Nimbus::API qw( nimLog );

{
    no warnings ...;
    sub nimLog {
        ...
        Nimbus::API::nimLog( ... );
        ...
    }
}

    [download]

    vs 

    # Sanity restored
use Nimbus::API qw( );

sub nimLog {
    ...
    Nimbus::API::nimLog( ... );
    ...
}

    [download]

    My question stands.

[reply]
[d/l]
[select]

      I do not know why Nimbus::API::nimLog has a prototype. It is one method of the supplier's core Nimbus::API which is compiled C++ for which we have no source

      I use Nimbus::API::nimLog because it is part of the product suite I am developing for. The rest of the product uses this logging module, by using it too my log level, log file, log truncation and remote log viewing through the GUI are all the same and controlled by the same settings as the core of the Nimbus product. Scripts I write are rolled out by our support team and any behavioural difference between the bits I wrote and the parts where I rolled in modules from the supplier or the 100% supplier parts would cause mighty confusion.

      Using the # Sanity restored sub would mean I would have to re-implement the nimLog method for no discernible profit, I figured it was easier to redefine the sub to do what I want then invoke the original to perform the logging in the standard Nimbus way.

      Cheers,
      R.

      Pereant, qui ante nos nostra dixerunt!
[reply]
[d/l]
[select]

        It is one method of the supplier's core Nimbus::API

        Not your code, got it.

        Using the # Sanity restored sub would mean I would have to re-implement the nimLog method for no discernible profit,

        What are you talking about? I don't know where you got the idea that I said you should change nimLog. It doesn't require any change to Nimbus::API, the original nimLog or to the one you are writing.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom