That said, it does have its uses. For instance, in a system I'm working on we have a set of methods that we need to be able to call on any object, and which can and should be overridden where necessary in client software. There's another set of methods that need to be callable on any object that should be considered as 'final'; in other words, we don't want client code overriding them.
To do this, we take advantage of the way perl will allow you to call fully qualified packages. Our overrideable methods all get put in UNIVERSAL, with a px_ prefix to prevent method name collisions with other objects, and methods that we need to be final get put into a PIXIE::* package.
Why do this? Because we want to maintain uniform access to methods. We could just make subroutine calls on objects for the 'final' methods and method calls for those methods in UNIVERSAL but we took the view that we wanted to maintain OO calling style. If the method calling overhead proves to be a significant issue when we come to do profiling, then of course we'll look at switching to direct function calls, but for now we'll stick with method calls throughout.
Note too that we're careful, in writing our PIXIE::* methods to make them dependent only on other PIXIE::* and px_* methods, and not to go making assumptions about the internal structure of objects on which they are called.
In reply to Re: Invoking method in another package
by pdcawley
in thread Invoking method in another package
by nutshell
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |