Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:
- basics
- regex
- all datastructures ( list, hash, nested )
- grep, map kind of built ins,
- used lot of modules
- wrote a couple of modules,
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.
|
---|
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 | |
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. | [reply] |
Re: kind of effort required for learning OO perl ?!
by morgon (Priest) on Jul 29, 2010 at 14:35 UTC | |
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. | [reply] |
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. | [reply] [d/l] [select] |
Re: kind of effort required for learning OO perl ?!
by Neighbour (Friar) on Jul 29, 2010 at 14:37 UTC | |
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. | [reply] |
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. | [reply] |
Re: kind of effort required for learning OO perl ?!
by targetsmart (Curate) on Jul 29, 2010 at 14:38 UTC | |
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. | [reply] |
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: 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.
| [reply] |
by punkish (Priest) on Jul 30, 2010 at 02:28 UTC | |
BrowserUk, please educate me and others. Thanks in advance.
--
when small people start casting long shadows, it is time to go to bed | [reply] |
by BrowserUk (Patriarch) on Jul 30, 2010 at 05:16 UTC | |
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: 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. 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.
| [reply] |
by Anonymous Monk on Dec 12, 2012 at 23:27 UTC | |
by BrowserUk (Patriarch) on Dec 13, 2012 at 12:00 UTC | |
by chromatic (Archbishop) on Jul 30, 2010 at 05:47 UTC | |
If you want to learn OO well and don't mind exploring a language besides Perl, Eiffel is a good candidate. Smalltalk is another. | [reply] |
by JavaFan (Canon) on Jul 30, 2010 at 08:14 UTC | |
by BrowserUk (Patriarch) on Jul 30, 2010 at 08:45 UTC | |
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!):
Then you'd write your code to address the data structure. Say you want to print a list, with the basic info:
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.
Now you go to your main package and create and populate objects.
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 | [reply] [d/l] [select] |
by Your Mother (Archbishop) on Jul 29, 2010 at 22:56 UTC | |
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. :) | [reply] |
by furry_marmot (Pilgrim) on Jul 31, 2010 at 03:27 UTC | |
| [reply] |
Re: kind of effort required for learning OO perl ?!
by LanX (Saint) on Jul 29, 2010 at 17:52 UTC | |
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 | [reply] |
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. | [reply] |
Re: kind of effort required for learning OO perl ?!
by InfiniteSilence (Curate) on Jul 29, 2010 at 18:50 UTC | |
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 | [reply] [d/l] |
by chromatic (Archbishop) on Jul 29, 2010 at 19:25 UTC | |
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. | [reply] [d/l] [select] |
by InfiniteSilence (Curate) on Jul 29, 2010 at 21:56 UTC | |
? I borrowed this syntax from the perlbot example: When I checked that $self reference was indeed blessed before it was passed through bless again: What is the harm? Celebrate Intellectual Diversity | [reply] [d/l] [select] |
by chromatic (Archbishop) on Jul 29, 2010 at 23:08 UTC | |
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. 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. | [reply] |
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:
- 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). | [reply] [d/l] |
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. Good luck!! | [reply] |
Re: kind of effort required for learning OO perl ?!
by petecm99 (Pilgrim) on Jul 30, 2010 at 13:01 UTC | |
OMG Did I just say that?! Aaaaaah! I should get more sleep. ;) | [reply] |