[Nagiosplug-devel] Re: Last call for Perl-plugin-objects

[Paul L. Allen]

Karl DeBisschop writes: 

> 2) you agree that the performance cost is acceptable. 
> 
> I can try to work on #1, but as noted above, free time is presently near
> zero. 
> 
> As far as #2, the judgment call is entirely in your court as far as I am
> concerned. 
> 
> As usual, people may disagree. But those are my opinions on the matter.

Perl's OOP does have significant performance costs.  I have to say that
I see no compelling reason for switching to an OOP model for the case of
plugins.  In some cases OOP results in drastically-simplified code leading
to far greater ease of developing and maintaining code.  In other cases,
OOP is obfuscatory bloat that makes it difficult to maintain stuff.  Where
you draw the line is a matter of personal taste and experience. 

I agree that utils.pm should be extended so it supplies most of the
functionality that is common to most plugins.  A routine which takes
levels specified in any of the x:y variants and compares a value against
the trigger levels then returns OK/not OK would be very useful.  There
are plenty of other bits of functionality that could usefully be
factored into utils.pm.  Having utils.pm create an array that translates
return codes to text messages from %ERRORS would be useful.  Etc.  That
makes it easy to extend the functionality of those bits of code and have
the changes automatically reflected in all the plugins that use it.  But
those sorts of things don't need to be OOP, as far as I can see. 

Let's face it, most of Perl's OOP functionality is really using pre-OOP
perl behind the scenes anyway.  Setting up methods and classes so you can
supply defaults that can be over-ridden is a very expensive alternative to
stuff like "local($x) = shift(@_) || $x" in a subroutine (yes, I know
the pitfalls of local). 

-- 
Paul Allen
Softflare Support