It's one of the advantages of perl, IMO. One of the problems with object-oriented programming, as I see it, is that there's an internal pressure to make your classes "complete" so that users can do all the tasks they would reasonably expect to be able to do with the class. Many languages require that a class be created in a single source file, so frequently you'll get occasionally useful functionality thrown into the file, when most applications don't actually need it. As the class ages, more and more stuff gets put in there.
The ability to add some functionality to a class without inheriting from it is pretty nice, as you can simply include other modules at the top of your program. So if you need some rarely-needed functionality, you don't need to subclass something to add the functionality and then update your script to use the new subclass. Using your extra functions with another package of extra functions is similarly easy, just add the functions into your class and you're done. No need to refactor your application, no need to worry about how to refactor the extra functions into yet another class hierarchy to let them coexist.
If it's truly a one-off function, you can just add it into your script, and it'll still act as if it were part of the package proper.
It's not something you'll need to do all the time, but it's flexible and clean, compared to having to worry about inheritance headaches.
...roboticus
When your only tool is a hammer, all problems look like your thumb.
In reply to Re: Packages with subs using fully qualified class names, not always their own.
by roboticus
in thread Packages with subs using fully qualified class names, not always their own.
by SimonSaysCake
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |