|Do you know where your variables are?|
$functions xor $methodsby Ovid (Cardinal)
|on Oct 30, 2002 at 00:09 UTC||Need Help??|
Recently, I was pointing out the difficulty with subclassing a particular module. The module appeared to be object-oriented and useful, but it lacked some functionality that I needed. The answer? Subclass it!
The module, Data::FormValidator, makes a mistake that I see all too frequently and that, frankly, I have been guilty of in the past. It appears to be object oriented, but it uses function calls internally, rather than method calls. While I pointed this out in the post I referred to, this problem seems common enough that I feel it deserves a root node.
That might look perfectly reasonable at first, but what happens if I need to subclass this method and I need _some_function()? I can no longer call _some_function() directly as my subclass will be in a different namespace. I can't do $self->_some_function() as I have now added $self as the first argument. Reimplementing _some_function() in my subclass means that I'm duplicating code or using it as a wrapper around an ugly construct like the following:
Needless to say, the above eliminates many of the benefits of subclassing. The following code may illustrate the problem more clearly.
That prints out something similar to the following:
If you're going to use object oriented programming, use method calls. Don't use functions.
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.