Re: $functions xor $methods

I understand your frustration but you are just wrong.

Object oriented inheritance is not about reading the implementation of your SUPER classes.

If you are overriding method you should expect to reimplement it.

Consider: if the _helper_function's effect was contained in the method, you would not be complaining, but you would still have to reimplement the effect.

The SUPER class author is telling you outright not to count on the interface of _helper_function.

Just be happy he gave you an example implementation.

If you're going to use object programming, use method calls. Don't use functions.

Exactly right, but this should be applied to yourself as a client writer.

Comment on Re: $functions xor $methods Select or Download Code

Replies are listed 'Best First'.
Re: Re: $functions xor $methods by Ovid (Cardinal) on Oct 30, 2002 at 17:34 UTC
Okay, I'll just fess up to now having doubts about what I wrote :) Clearly I shouldn't be worrying about an object's internals. As tye points out, subclassing modules that aren't designed to be subclassed is asking for trouble. The problem is, what do I do if I need a module's functionality but don't want to rewrite it? Looking at Data::FormValidator, for example, there are some features that I could use here at work, but make absolutely no sense to have in that module, so submitting a patch isn't right. Subclassing it also isn't an option because I'd be forced to rewrite virtually the entire module to support the features that I need -- and they still wouldn't be appropriate in that module (because they're tied very specifically to our business needs), so I'd still have to either subclass what I wrote or find a different method of solving my problem. In this case, that "different method" forced me to ignore a useful module that I wanted to use and rewrite it. Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply]
Re: Re: Re: $functions xor $methods by sauoq (Abbot) on Oct 30, 2002 at 22:51 UTC
The problem is, what do I do if I need a module's functionality but don't want to rewrite it? Two possibilities spring to mind. Simply write a module which uses the other. This is probably the appropriate way to do it if you are adding functionality to a module anyway. Subclassing, I think, is best when you want to change the functionality, particularly by making it more specific. A tried and true method that doesn't get enough respect these days is to create a copy of the module and modify it. Forking a module's development is a perfectly fine form of code reuse which, like any other, has its advantages and its disadvantages. -sauoq "My two cents aren't worth a dime.";	[reply]
Re^3: $functions xor $methods by Aristotle (Chancellor) on Oct 31, 2002 at 16:00 UTC
I am one of those few who have to watch for false hubris more than false laziness, so this is what I'd want to do: Patch the module to clean up the internals, and add hooks - whether that be subclassability, slots for user-supplied callbacks or whatever else may seem appropriate -, and of course submit the patch back to the author. Then I'd use the well-defined interface I just created to add my own, case-specific functionality inside my application. Hopefully the author will either accept the patch or be inspired - and so whoever next needs something like me will also benefit. Makeshifts last the longest.	[reply]