Uhhhh, maybe I can help you out with this mess, having been doing OO perl for 5 years or so now...
1st of all, if your classes are properly structured, then every method call should search for the proper method starting with the package into which the reference is blessed. This is ENTIRELY different from other OO languages like Java, where if you call a method in a superclass then any method calls from there on out are effectively made on a reference of the type of the superclass. In perl if package A overrides a method of package B, lets call it Z(), then even a call in B to Z() will call the version A->Z() because you are dealing with a reference blessed into package A. This is one reason that OO perl has a good bit of overhead, because effectively all method calls are (in C++ parlance, "virtual"). In more technical terms, perl always uses "late binding", whereas Java and C++ use "early binding" whenever possible. I haven't gone over the TLH code to see what the problem might be here, but it could be one of several things. First of all perhaps one of your classes is not properly blessing things. You should ALWAYS use the 2 argument form of bless. If not you may be ending up with a SUPER::new() call somewhere that erroneously blesses a reference to the superclass and not the subclass. Someone mentioned pushing onto @ISA in one response on this. Nope. Each package has its own @ISA. You would never push onto it, and you would never monkey with any other package's @ISA either. Another wrinkle can be with class data. @EXPORT_TAGLIB or similar things are static class level data. Depending on exactly how you define variables like this you may or may not get the sharing behaviour you might expect when dealing with subclasses. Unlike with methods, where ISA provides inheritance, variables are package specific and can't be inherited. If a subclass refers to a package variable using an unqualified statement, it will simply autovivify its own copy in its own package namespace (or you may get an exception, depending on "strict" and exactly when the statement executes). This can create some pretty subtle traps as well. The general rule to follow is to ALWAYS use class level methods to access class level data. That way you can inherit the accessor/mutator in a subclass and get the sort of behaviour you normally expect. If you guys are interested, I can give you boilerplate for class hierarchies. I've built some fairly extensive ones in perl and there shouldn't be any problems, but sometimes you can inadvertantly create oddball classes. One other perl oddity I have run into that might bite you once in a blue moon is the lexical variable bug. I've never seen this documented anywhere, nor been able to get any of the perl developer team to acknowledge this bug, but once in a while if you have a complex class structure you will suddenly get highly erratic behaviour from "my" variables when calling superclass functions. I assume its a stack framing problem or a symbol table bug of some kind, but I've had several cases where the value of "self" was completely bogus until I renamed it something like "foobar"!!! I haven't seen this problem in 5.6 though. It may have been fixed. On Monday 25 March 2002 01:46, Steve Willer wrote: > On Sun, 24 Mar 2002, Matt Sergeant wrote: > > But, if I comment out the sub parse_* functions, it fails to work, even > > though the functions themselves simply call their SUPER method of the > > same name!!! > > Hmm...I have a vague recollection of a problem where if a function in > package X calls A::parse_start, which doesn't exist but automatically goes > to its parent class function B::parse_start, then if B::parse_start called > caller() it would get 'X' as a response. > > I couldn't figure out a way to get B to see that it was being inherited > from by A in this case. B needs to see A because TLH (B in this example) > has to know where to find the @EXPORT_TAGLIB array. > > I feel badly about it, because I gave up after only perhaps a day or two > of fiddling around. Now it's been released and is being used, and maybe > we're stuck with this yuckiness. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
