http://www.perlmonks.org?node_id=851948

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

Hello Monks, I would like to know what is the kind of Effort required to learn OO Perl. I've expertise in Scripting Perl, i do the following things very well, And i have a pretty good experience in IT field, and am a normal learner. Can somebody give me an idea that, how much time/days it would take for me to become expert in OO Perl ?
Also, i have confusion in what is OO perl ? Please what exactly this means ?
Please point me to some document which i can use to learn OOperl from scripting Perl.
  • Comment on kind of effort required for learning OO perl ?!

Replies are listed 'Best First'.
Re: kind of effort required for learning OO perl ?!
by kennethk (Abbot) on Jul 29, 2010 at 14:42 UTC
    The usual references for how object-oriented Perl works are perlobj, perlboot and perltoot. These describe the mechanics of constructing the appropriate modules and interacting with objects. Many people choose to use previously-rolled object-oriented frameworks in actually building their code. Examples of these include Moose and Mouse.
    Can somebody give me an idea that, how much time/days it would take for me to become expert in OO Perl ?
    The term "expert" gives me pause. I am certainly competent with Perl in general and OO Perl in particular, but I would by no means characterize myself as an "expert" after years of work and study. Your mileage may vary.
    Also, i have confusion in what is OO perl ? Please what exactly this means ?

    Object_oriented_programming is a programming paradigm, which is to say a philosophy of how to build code. Some languages, Java being first in my mind, are built around the idea. In Perl, on the other hand, it is simply an approach to designing one's code. At its simplest level, it just means using blessed objects to maintain context for method calls.

Re: kind of effort required for learning OO perl ?!
by morgon (Priest) on Jul 29, 2010 at 14:35 UTC
    It is impossible to estimate the time it would take you to become proficient in OO-Perl.

    As you already know Perl it would mainly depend on how much background about OO-principles you bring from other languages.

    I think a good starting point for you would be Damian Conways's book "Object oriented Perl".

    It is a couple of years old, but it is still a good intoduction to (pre-Moose) OO-Perl.

    Read that first and then take a look at Moose.

Re: kind of effort required for learning OO perl ?!
by hardburn (Abbot) on Jul 29, 2010 at 14:52 UTC

    If you know about packages and references, then taking the next step to OO Perl is easy. You use bless to put a little note on a reference, which will be the package for looking up methods. So whenever you do $obj->foo, it's looking up the foo() subroutine in the package you bless'd into.

    For the basics, there isn't much more to it then that. The trick is not making it out to be more complicated than it is. OO Perl is just straightforward combinations of stuff you probably already know.


    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re: kind of effort required for learning OO perl ?!
by Neighbour (Friar) on Jul 29, 2010 at 14:37 UTC
    I'll just answer the easiest question and leave the others to my more OO-confident brethren:

    http://perldoc.perl.org/perlobj.html contains information on how perl handles objects, and enough references for further reading to keep you busy for the day. Once you get the hang of that, there are also plenty of CPAN modules to use for OO programming, the most well-known being Moose.

Re: kind of effort required for learning OO perl ?!
by chromatic (Archbishop) on Jul 29, 2010 at 16:03 UTC

    I find the core documentation incomplete, misleading in places, and generally out of date. The draft of my Modern Perl book has several sections on OO programming in Perl which I hope are useful to people in your circumstances.

    I welcome any feedback, if you have time.

Re: kind of effort required for learning OO perl ?!
by targetsmart (Curate) on Jul 29, 2010 at 14:38 UTC
    Object oriented perl is a good step to start with.
    Moose http://www.iinteractive.com/moose/ is also interesting.
    perlobj is also a place to start.

    Vivek
    -- 'I' am not the body, 'I' am the 'soul/consciousness', which has no beginning or no end, no attachment or no aversion, nothing to attain or lose.
Re: kind of effort required for learning OO perl ?!
by BrowserUk (Patriarch) on Jul 30, 2010 at 00:56 UTC

    If you want to learn the use of OO in Perl and have time (say 2 to 4 weeks of evenings) to play:

    • start with the perldocs perlobj, perlboot & perltoot to get an understanding of how the mechanics of OO works.
    • Once you get bored with reconstructing those mechanics manually each time, do the Moose tutorial thing. (Another 2 to 4 weeks say.)
    • Once you get fed up with the performance; you might decide that you don't need all the bells and whistles; and that actually, reconstructing the mechanics manually isn't so arduous after all.

    If you want to understand the right way to think about problems, in a manner that will allow you to use OO effectively and maintainably, download an Eiffel compiler and splash out on Object-Oriented Software Construction, 2nd Edition by Bertrand Meyer.

    Neither a cheap, nor easy, nor quick option, it will make you think about software and software development in a completely different way than if you acquire your OO knowledge in a piecemeal fashion. And you will never regret it.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      I have to admit up-front that I am biased favorably toward listening to BrowserUk's advice. So, I want to take the advice seriously, but I am trying to understand where it would lead me? Should I go the traditional Perl OO route? Should I go the Moose route? Should I go back to the traditional Perl OO route? Or, should I chuck it all and work with a grounds-up OO language (not something I am going to do without very good reason) such as Eiffel, which, eventually gets compiled into C anyway (via SmartEiffel compiler).

      BrowserUk, please educate me and others.

      Thanks in advance.

      --

      when small people start casting long shadows, it is time to go to bed
        Or, should I chuck it all

        Learning a new language, especially in order to become familiar with a new paradigm, does not imply that you forget or stop using what you already know. Not even vaguely.

        Over the last 8 years I've experimented with a variety of FP languages--Haskell, Caml, Mozart/Oz, Erlang, Q/Pure amongst others--specifically to get a handle on FP. And I believe that those efforts have greatly benefitted my approach to solving some types of problems. But I still use Perl as my first choice when I need to get something done. And revert to C when I need to do (parts of) it more quickly.

        I encountered Eiffel--actually an OU teaching variant call Small Eiffel--and OOSC when mentoring a mature OU undergrad, 15 or so years ago. I'd done various forms of OO programming before that, including some fairly in-depth (v.large project; huge overall system complexity) in C++. My C++ skills were rated (by others) as "above average"; but I hated it!

        I hated it because nothing was simple; nothing was intuitive; nothing was elegant. Nothing ever seemed to be really "right". There were always compromises. Too many compromises. Even as we were gathering the plaudits for a job well done, having met all the requirements & performance criteria; and passed all the tests. The customer had signed off and agreed to completion bonuses. I still had nagging doubts. And I was not the only one on the team with them, though we mostly kept them to ourselves.

        It wasn't until I read OOSC, and worked with Eiffel that I understood why.

        The 'add-on' nature of C++, especially back then, means that it is not just far too easy, but you are actively encouraged, to think of OO as a way to create a convenient set of name-spaces in which to stick your data and subroutines. And for large numbers of OO programmers in many languages, that is pretty much all they get from OO; and they are happy that way.

        What Meyer taught me was that OO is far less about the mechanics of hiding your data & methods behind name-spaces; and far more about modeling your application in its own terms. Sorry for the emphasis, but its an important point that I will strive to explain.

        Far too often, classes and class hierarchies are modelled around concepts like numbers(subdivided into integers and reals(further subdivided into 8/16/32/64-bits etc.), strings(subdivided into various fixed and variable lengths), Persons(subdivided into employees, customers; and then managers etc.), polygons(subdivided into squares, circles etc.). And each of these low-level classes are written (or supplied or bought in as libraries) to be complete. So numeric classes not only know how to add, subtract, multiply, divide and compare themselves; but also how to integrate and differentiate and calculate Bessel functions et al. that a complete math library should.

        The problem is, at the top levels of any particular application (suite), the entities required are hybrid. The data comes into the program in a file that contains strings. Within those strings are names, ages, addresses, zipcodes, versions, dates, times, places, quantities in a variety of units, sounds, colors, distances, routes, feelings, truths and speculations.

        And those high-level entities are constructed--through composition or multi-inheritance--from a rag bag of the low-level entities. And so you end up with things like:

        Addresses split into:

        1. StreetNo (int)--which screws up when it is '221a'--despite that you never perform math with street numbers.
        2. First line (char80) -- In the UK this is streetname; in the Netherlands it is the Town.
        3. Second line (char80)
        4. TownOrCity (char40) -- what if I live in a village or hamlet or on an island?
        5. County/State/Region (char40)-- Um. Monaco (or Andorra).
        6. Country (char20) -- Monaco (Andorra).
        7. ZIPCODE/POSTCODE/ (char8) -- Just too damn bad if you live in Iran with their 10 digit post codes.

        Personnel applications where job description is an attribute of the Employee, when the jobs are the constant and the people come go and move.

        Version number stored as floats.

        And each of those objects brings in huge chunks of the underlying class library code that the application will never use. Eg. You'll never need to run a Bessel function on a version number. And with it, you get a whole bunch of parameter validation at each of those lower levels that is (should be) redundant, because the higher level composing classes perform their parameter validation where it should be done--on input.

        To answer your 3 questions.

        • I believe that understanding how the mechanics of OO works is very important when it comes to debugging.

          Working out why your code is producing weird results, because you've derived from two classes that have a common method name, if you don't understand the mechanisms of inheritance, is almost impossible. And Perl's 'native OO' gives you a better insight to that than just about any other language I'm aware of.

          But it is far too easy to get wrapped up in the details of those mechanisms, and loose sight of the overall problem you are trying to solve. And that can lead to OO myopia. To the concentration upon writing good OO at the expense of solving the overall problem cleanly, efficiently, and maintainably.

          I think that OO-spaghetti is far harder to debug than procedural spaghetti. And that these days, OO-spaghetti is far more prevalent simply because the problems with gotos and globals etc. are very well known and talked about. But everything OO feels like you're doing the right thing.

        • I think if you need to get something going quickly, you'll probably get there quicker with Moose than without it. And most of the time it will probably work.

          But without the grounding of understanding what Moose is doing for you under the covers, when it goes wrong, whether through your fault or theirs, you'll be up shit creek without a paddle.

          I also think that Moose comes with an agenda and an underlying philosophy that means if that is your first experience of OO, you're likely to find yourself bewildered and confused if you have to move away from that to (say) Java, C++ or JS.

          It may also lead to the same kind of OO myopia I mentioned above.

        • Whether you will find the performance of Moose limiting will very much depend upon the type of programming you do.

          If everything you do is IO-limited, perhaps not. If you write anything that is CPU-bound for more than a few minutes, you'll definitely notice it.

          The problem is that it isn't really possible to just re-write the slow bits of your Moose application in Inline::C or XS, because the overhead is not in your code, but in the (now hidden) mechanics of the OO itself.

          OO encourages the use of myriad small methods calling other methods calling other methods. Put those in loops--and all CPU-bound code involves loops--and you multiply the cost of Perl's sluggish function calls over and over. Be overzealous with your parameter validation, add in a little runtime introspection, and you are going to notice.

          And once you notice, you might be tempted to measure. And once you measure, you might find yourself wondering what all that overhead is buying you.

        • If you have the time, or the inclination to make the time, then I seriously doubt that you would ever regret learning enough Eiffel to get you through--the first few chapters at least--of OOSC.

          I also seriously doubt many people will move over to Eiffel as their main or only language; or even use it for paying commercial work. But like those that got to grips with Lisp early in their careers say, it will influence everything you write from then on, whatever language you write it in.

        The (my) bottom line. If you have the time, try all three: Perl basic OO; Moose; and Eiffel+OOSC. If you don't have the time, make the time. If not now, then over the next few weeks or months. Each will benefit you.

        If I didn't know PBOO, and had to get something together now. I'd go the Moose route. But I'd stick to the Moose basics, and not get caught up in trying to use every bell and whistle. I'd use only what I needed. To avoid lock-in and overhead.

        And then make the time to go back and try the other two.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        If you want to learn OO well and don't mind exploring a language besides Perl, Eiffel is a good candidate. Smalltalk is another.

Re: kind of effort required for learning OO perl ?!
by furry_marmot (Pilgrim) on Jul 29, 2010 at 22:26 UTC

    The advice is getting a little thick here, so I thought I'd offer simplicity. First, I'd go with Morgon's advice and track down a copy of Damian Conway's Object-Oriented Perl. Also try Intermediate Perl. You might get lucky and find either or both at your local library.

    If you're asking what OO Perl is, either you don't know what OO programming is, or you don't know what it would mean in Perl. So I'll give you a couple of basics. After that, I'd suggest you pick a super-trivial task and roll your own objects. Then re-read whatever you've got on hand. It should make more sense then.

    OO programming simply inverts functions and data, after a fashion. So instead of maintaining a large data structure and writing code to access it, you refactor down what one record should look like, and then you create a class that represents that record. Objects are references. Classes are packages. Methods are functions. When you refer to $this_obj->name(), it runs the function name() in the class you created $this_obj from, but $this_obj has its own copy of the function and the data.

    Off the cuff, let's say you want to write a little database to store your DVD's. I'm ignoring persistence issues.

    The procedural way in Perl would probably be to create a hash, something like this (you'd probably use ISBN numbers, but c'mon, it's just an example!):

    %movies = ( 'Gone with the Wind' => { year => 1939, stars => ['Clark Gable', 'Vivien Leigh'], director => 'George Cukor' }, 'Wizard of Oz, The' => { year => 1939, stars => ['Judy Garland', 'Billie Burke'], director => 'Victor Fleming' } # etc. );

    Then you'd write your code to address the data structure. Say you want to print a list, with the basic info:

    for $key (sort keys %movies) { print "$key:\n"; print " Year: $movies{$key}->{year}\n"; print " Stars: ", join(', ', @{ $movies{$key}->{stars} }), "\n"; print " Director: $movies{$key}->{director}\n\n"; } ------------------Prints-------------- Gone with the Wind: Year: 1939 Stars: Clark Gable, Vivien Leigh Director: George Cukor Wizard of Oz, The: Year: 1939 Stars: Judy Garland, Billie Burke Director: Victor Fleming

    Mmmmmm! Yummy mush code! And with dereferencing sorbet for dessert! An important reason for object-oriented programming is to hide all the messy details in the object code (often in another file). There's also encapsulation and inheritance, but learn how to make it work first.

    Below is the code for a class of pitifully inadequate DVD objects.

    package MyDVDs; # Creates a reference as a hash ref, "blesses it" into the # current package, and returns the reference. sub new { my $self = {}; bless $self; return $self; } # Simple get/set accessor. If you pass it something, it will add or # replace (set) whatever is there. Always returns whatever it has (get +). sub title { my $self = shift; $self->{title} = shift if @_; return $self->{title}; } sub year { my $self = shift; $self->{year} = shift if @_; return $self->{year}; } # A variation, storing data in an array. A simple improvement might be # to remove duplicates. sub stars { my $self = shift; push @{$self->{stars}}, @_ if @_; return join(', ', @{$self->{stars}}); } sub director { my $self = shift; $self->{director} = shift if @_; return $self->{director}; }

    Now you go to your main package and create and populate objects.

    use MyDVDs; # You'd probably load this directly from some source, creating anonymo +us # objects and sticking them in an array, but I have to go to a meeting + soon... # Notice how easy it is simple it is to add data. my $movie1 = MyDVDs->new; $movie1->title('Gone with the Wind'); $movie1->year(1939); $movie1->stars('Clark Gable', 'Vivien Leigh'); $movie1->director('George Cukor'); my $movie2 = MyDVDs->new; $movie2->title('Wizard of Oz'); $movie2->year(1939); $movie2->stars('Judy Garland', 'Billie Burke'); $movie2->director('Victor Fleming'); push @list, $movie1, $movie2; # And how is this for simplicity of accessing the data? for $movie (@list) { print $movie->title, ":\n", " ", $movie->year, "\n", " ", $movie->stars, "\n", " ", $movie->director, "\n\n"; } ------------------Prints-------------- Gone with the Wind: Year: 1939 Stars: Clark Gable, Vivien Leigh Director: George Cukor Wizard of Oz, The: Year: 1939 Stars: Judy Garland, Billie Burke Director: Victor Fleming

    Inserting code into the objects is super easy, as is accessing the data, without having to remember how to dereference even the most complicated data structures. When you think you have your mind wrapped around it, check out Moose. There's a LOT you can do with that, but it will make much more sense once you've seen how it all fits together. Designing OO systems can be hard. But using them is usually pretty easy.

    --marmot
      The advice is getting a little thick here, so I thought I'd offer simplicity.

      No critique of content, just to remark that for thin simplicity it certainly is the longest reply. :)

        Obviously (he says, hoping it was obvious), I was referring to foisting techniques or Moose on someone who may not even know what OOP is, but <sheepish>Yeeeeaaaahhh, I kind of noticed that myself. </sheepish>
Re: kind of effort required for learning OO perl ?!
by LanX (Saint) on Jul 29, 2010 at 17:52 UTC
    Perl has a "RISC approach" to OOP, that means you have little brickstones allowing to assemble a multitude of different OO-Models.

    e.g you are free to chose the datastructure holding the data of an instance (the ref you are blessing) and you have to gather the $self variable referncing this data and you can use closures to hide various private aspects and so on.

    If you simply want to be productive right away try to read the Moose-Tutorial. Moose is one of the more elaborated projects to compose a complex model without you needing to do every single step manually.

    But if you want to understand the technique used in various CPAN-Moduls using these basic techniques I recommend Object oriented Perl from Damian Conway

    UPDATE: This book will not only teach you the generality of how Perl achieves OOP, but how different the models in different languages can be.

    OOP isn't the same in Ruby, Python, JS or JAVA but Perl can simulate all these models.

    Cheers Rolf

Re: kind of effort required for learning OO perl ?!
by JavaFan (Canon) on Jul 29, 2010 at 17:08 UTC
    And i have a pretty good experience in IT field, and am a normal learner. Can somebody give me an idea that, how much time/days it would take for me to become expert in OO Perl ?
    Depending on what you consider an 'expert', I'd say anywhere from 4 hours to 16 years.
Re: kind of effort required for learning OO perl ?!
by InfiniteSilence (Curate) on Jul 29, 2010 at 18:50 UTC
    According to most online sources OO programming involves three basic elements: inheritance, polymorphism, and data encapsulation (see references included in the code). Some examples of basic ways to achieve these are below.
    #... http://www.cs.mun.ca/~donald/bsc/node12.html # INHERITANCE package dog; sub new { my $class = shift; return(bless({'puppies'=>15},$class)); } sub get { my ($self,$name) = @_; return ($self->{$name}); } sub set { my ($self, $name, $newvalue) = @_; #this is silly but saves space $self->{$name} = $newvalue; return $self->{$name}; } sub bark { return 'woof...I INHERITED this capability.'; } package cockerSpaniel; use parent -norequire, qw|dog|; sub new { my ($class) = @_; return(bless(dog->new(),$class)); } sub bark { my ($class) = @_; return ($class->SUPER::bark() . '..but then overrode it'); } package main; my $doggie = new cockerSpaniel(); $doggie->set('puppies',29); print qq|\nHere are the cockerSpaniel's puppies: | . $doggie->get('pup +pies'); my $realdog = new dog(); print qq|\nHere are the parent dog's puppies: | . $realdog->get('puppi +es'); # POLYMORPHISM, or dynamic binding of function calls print qq|\n| . $doggie->bark(); # Data Encapsulation # There are numerous techniques. Take your pick: # http://www.csse.monash.edu.au/~damian/TPC/1999/Encapsulation/Paper.h +tml
    The above, with the reading, should take only about an hour or so to learn. It is good, in my opinion, to learn the old non-Moose way of defining classes since there is so much code out there that uses these techniques. The problem that I have seen with OO programming in general has little to do with the techniques or semantics -- it has to do with learning to think in an object oriented way. For this I recommend using something entirely outside of the scope of a particular language. I recommend reading Object Thinking by David West (don't worry that is was published by Microsoft Press...this book was published under an experiment where no Microsoft technologies were discussed in the book). Here you will learn not just terminology and the mechanics of how to migrate from top-down to OO, but how to use nomenclatures and tools (CRC cards, for instance) that will help you describe and analyze problems before you write code.

    Celebrate Intellectual Diversity

      I can't recommend some of this advice; it looks prone to making messes.

      package dog;

      Lowercase module names are, by convention, pragmas.

          return(bless(dog->new(),$class));

      Why double bless? If the parent constructor is at all sane, it allows subclassing.

      my $doggie = new cockerSpaniel();

      The indirect method invocation syntax is fraught with peril; it's ambiguous to parse and Perl occasionally guesses incorrectly depending on the compilation order of your code.

      Also inheritance is not an essential part of object orientation. Arguably neither is encapsulation.

      You're absolutely right about object design being important. Most tutorials never teach that, and it's vital to writing effective OO.

        What double bless...are you referring to this:
        sub new { my ($class) = @_; return(bless(dog->new(),$class)); }
        ?

        I borrowed this syntax from the perlbot example:

        sub new { my $type = shift; my $self = Bar->new; $self->{'biz'} = 11; bless $self, $type; }
        When I checked that $self reference was indeed blessed before it was passed through bless again:
        DB<3> p UNIVERSAL::isa($self,'Bar'); 1
        What is the harm?

        Celebrate Intellectual Diversity

Re: kind of effort required for learning OO perl ?!
by Anonymous Monk on Jul 30, 2010 at 03:45 UTC

    Hi Anon Monk.

    For some perspective, note that there are really 2 schools of thought regarding object oriented programming with Perl 5.

    1. The first is that you should follow the old, spartan, and fast way of using blessed hash refs. This is what's described in the perlboot and perltoot tutorials. This is the bare-bones old-school way of doing OO Perl 5. In the event of explosive decompression, please note that your seat cushion can be used as a flotation device.
    2. The other school of thought is to use modern, more advanced, much easier to use, but slightly slower technology. The advice here is to use Moose. Moose provides features somewhat similar to Perl 6 OO.

    Before Moose came along, people had struggled with Perl 5 OO and invented a number of creative and/or dodgy ways to deal with and use it. My suggestion to you is to just use Moose. A number of the Perl 5 olde guard do not recommend Moose.

    As for how much effort it will be to learn OO, my answer is: not much. It's pretty simple. You look at the problem you're trying to solve and decide what the nouns are and what they should be able to do. OO features will allow you to soon create a data structure that contains not only data having to do with this noun, but also functions to operate on that data (this structure is called an "object"). The way you create objects is to first write down a model for what they should look like (a "class", which lists all the data and functions you want associated with that data). Then you call the class (as if it were a function) to create the object for you. Once you've got your object, you can set the values of its data structure, and call its functions. Those are the basics. There's a couple extra OO features you will learn about after that, for example, classes can contain (as part of their data) objects of other classes. Also, you can write one class, and then if you want a similar-but-more-specialized class, instead of writing out the first one all over again plus a few extra bits, you can just "inherit" from the first one and then throw in the new extra bits. Not rocket science -- it'll take you an evening or two to get the basics.

Re: kind of effort required for learning OO perl ?!
by ivo_ac (Acolyte) on Jul 31, 2010 at 05:08 UTC

    Hi,

    I learned OO Perl from the book "Object oriented Perl". Its pretty old so you can buy it second hand real cheap but its a jewel.

    OO Perl is very easy, it uses 3 steps:

    - To create a class, create a package

    Just as you normally create a package, but do not export anything.

    - To create methods, write subroutines

    Methods are just subroutines, but instead of using the data in a class, they use the pointer to a blessed hash. Example:

    sub return_output { my ($self,%args) = @_; return $self->{output}; }

    - To create objects, bless a referent

    The constructor blesses a reference to an anonymous hash and returns it. It uses function bless for this.

    So its real easy, if I were you I would start with reading "Object oriented Perl" (as I did recently, I bought the book second hand for 5 euros but its worth much more).

Re: kind of effort required for learning OO perl ?!
by tospo (Hermit) on Jul 30, 2010 at 09:28 UTC

    I have fairly recently been through this process myself and I can assure you that it is a) worth it and b) not nearly as complicated as it may seem in the beginning. I think the trick is to avoid reading the computing science literature about OO design and just get your hands dirty ASAP.

    I think the best way to start is to identify the need and the benfit, which gives you the right incentive.
    For example, you might notice that your data-structures are gettng more and more complex and that your scripts are modifying values deep inside nested hashes of arrays or something like that (happened to me). Then you might think "wouldn't it be nice if I could just tell my script that this datastructure is an object that knows how to do certain things?", i.e. think of the interface you would like to use in an ideal world and then write an OO module to provide that. The satisfaction you will gain next time when you can write in another script My::ProblemSolver->solve_problem is worth the effort ;-)

    Good luck!!

Re: kind of effort required for learning OO perl ?!
by petecm99 (Pilgrim) on Jul 30, 2010 at 13:01 UTC
    Don't waste your time - bag the whole idea and just use Cobol.

    OMG Did I just say that?! Aaaaaah! I should get more sleep. ;)