in reply to override prototype

First, why are you using a prototype at all?

Second, why do you import nimLog if you're going to replace the imported symbol?

Finally, the so-called errors is simply an expected warning that can be silenced by changing

no warnings qw(redefine);
to
no warnings qw( redefine prototype );

Replies are listed 'Best First'.
Re^2: override prototype
by Random_Walk (Prior) on Jan 25, 2010 at 16:54 UTC

    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!

      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( ... ); ... } }

      vs

      # Sanity restored use Nimbus::API qw( ); sub nimLog { ... Nimbus::API::nimLog( ... ); ... }

      My question stands.

        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!