On Thu, Nov 25, 2004 at 12:03:55AM +1100, Michael S. E. Kraus wrote: > Am I asking to higher a level a question to be appropriate for this > list?
It's a more advanced question than most, but not inappropriate for this list, I think. You may also wish to consider comp.lang.perl.misc or perlmonks for further insight. But you should also consider that many of those who could answer your question were asleep when you posted it. > On Wed, 2004-11-24 at 17:35, Michael Kraus wrote: > > G'day... > > > > If a sublass has overrides a method in a superclass, and the subclasses > > method calls the superclass's method, is there any mechanism to detect > > that the superclass' method has been overridden? > > > > I'm wanting to write a method in an abstract class that must be > > overriden by it's children. If it is called directly (i.e. without being > > overriden) then it registers an error, but if its called via an > > overriding method then do some common functionality. > > > > I'm guessing there is no in-built functionality for this, and I'll have > > to examine my classes to discover how to test for it myself. Is it > > possible to confirm this? The key bit of information you have is the class of your object. You also have the name of the package you are currently in and the can() method or function. I'm not certain whether your aim is to ensure that developers subclassing the superclass do it correctly, or that users don't do something they shouldn't. Assuming the latter, the perl way of handling situations such as this is normally to document the interface and make it easy for people to use that rather than put checks all over the place to ensure people aren't subverting your API. The documentation puts it this way: Perl does not enforce private and public parts of its modules as you may have been used to in other languages like C++, Ada, or Modula-17. Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun. That said, and noting that any checks you make could be subverted by a sufficiently determined user of your module, I would suggest than an approach of ensuring that an object of the superclass type cannot be created should be sufficient. This can be done fairly simply by checking that the first argument to your constructor is not the name of the superclass. Further checks in the superclass methods are possible though there are normally superior ways of handling the problems which may be caused by users calling those methods incorrectly. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
