emagery has asked for the wisdom of the Perl Monks concerning the following question:

I'm new here, and I'm sure I'll seem newbiesque in the extreme to some... I've a talent for solutions and get great kicks out of combining artful code with artful graphics and making beautiful pages... and perl is my language of choice... but that's not to say I've had opportunity to dig very deeply into it...

But now I find myself taking over a client's site from a previous contractor, and finding myself in the deep end of the pool... the code style is all very object oriented and I'd never really had the opportunity to come to peace with the stuff.

There's my intro. Here's the problem. All throughout the site there are package .pm's defined at varying levels... you have these very low level .pms that handle all the SQL interactions so that later on you can simply use a $userID->{firstname} or some such and be done with it... forget all about MySQL if you feel like it. Other modules, via our apache.conf file, take over for /thisplace/ type URL subdirectories and run a specific module which includes calling templates and the like. All very well and good and comprehensible. But now I am on a subproject that requires that I turn an existing module into an administrative page that allows for the testing of LaTeX documents (don't worry, I'm not asking about that so much.)

As precedent, we have a file called Looks.pm that goes about lumping together said LaTeX code, creating DVI files, jpg previews, and .ps results. What I am trying to do is develop and admin subpage that instead of CREATING a LaTeX document, simply accepts one and then goes on to use Looks.pm's already existing functions for the generation of the jpg preview. I need, in otherwords, to use all the functions that already exist, but cut out the original function and supplant it with a simpler one of my own design... this is what I'd been described to as 'override' and I see things like this all throughout the site;
override( MODULE => 'XXX::XXXX', TEMPLATE_DIR => '/admin/blahblahblah/', CONFIG => 'XXX::Config', SUBS => { menu => \&buildtest, buildtest => \&buildtest, test => \&testresult }, );
which then is followed by new functions... unfortunately, the documentation behind the previous work is poor, and online and bookladen jargon is twisting me into knots trying simply to -fathom- the concept... in and ideal world, i'd simply define a new package, use an override like the one above, and define a follow sub to run instead of the similarly named parent package and thats it... that would make sense to me... but it hasn't worked and toying with the precedents hasn't led me to an epiphany as yet.

Knowing what I am trying to accomplish, can anyone, in plain english, bless me with some bit of understanding that I can go off and build upon?

Replies are listed 'Best First'.
Re: overrides?
by belg4mit (Prior) on May 31, 2002 at 01:58 UTC
    What you want is inheritance. You wish to inherit some of the properties of this other class. Check perl for the list of OO related man pages. Suffice it to say, it's not too complicated. You need to create your new class, within that class use the parent class (that from which you inherit) and then fiddle with @ISA (eg; @ISA = 'Class::Parent').

    --
    perl -pew "s/\b;([mnst])/'$1/g"

Re: overrides?
by Zaxo (Archbishop) on May 31, 2002 at 02:58 UTC

    The override you exhibit is, judging by it's syntax, a convenience sub which takes a list of key-value pairs. Presumably it sets those properties in an inherited object.

    Usually, function overriding occurs when a new version of a function is arranged to be found first by the compiler. Perl first looks for a sub in the current namespace, then starts scanning the @ISA list of namespaces, then main::. It uses the first it finds. In this case, it may be done instead by changing coderefs within the object itself.

    It sounds like you'd do well to start documenting the system as you go. 'All' you need to do is insert pod as you identify things in source. Good luck!

    After Compline,
    Zaxo

      I agree with Zaxo++ that it sounds like it's a convenience sub defined in one of your packages. I'd suggest you try to look it up, then look at what's inside to see how it works. My guess is that where you'll find it is the cornerstone of the system's design; in which case you're probably well off to spend some time reading there and as Zaxo said, to start documenting as you go.

      Incidentally, I have to say what you explain sounds like someone spent time to lay down a clean and concise design; kudos to whoever was your predecessor. I would advise you try to understand it all as much as possible and follow the spirit; lest maintenance work turns into a big ball of mud. Good luck :-)

      ____________
      Makeshifts last the longest.