Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Perl High School Graduation

by hsweet (Pilgrim)
on May 20, 2002 at 01:51 UTC ( #167752=perlquestion: print w/replies, xml ) Need Help??
hsweet has asked for the wisdom of the Perl Monks concerning the following question:

I'd like some ideas on how to explain the great mystery of objects and references to my class (and to myself, for that matter). My students at this point have some grasp of the basic Perl stuff, variables, hashes, control structures, input/output etc. I'd like to leave them with a taste of things to come without losing them.

I've had time since my first post to develop my Perl website at There is a page on objects there. I haven't used it yet with my students.

All the replies I got on my last post were very helpful

Replies are listed 'Best First'.
Re: Perl High School Graduation
by Zaxo (Archbishop) on May 20, 2002 at 02:10 UTC

    I'd suggest concentrating on references. They are more general and more fundamental than objects. The idioms of "pass by reference" vs "pass by value" and the related issues of aliasing vs deep copying are of prime importance in any serious programming environment.

    Object oriented programming is a very useful technique, but it's not the only such useful concept. That objects in perl are implemented as references to data structures is good for motivation, but facility with references is more important, in my opinion.

    After Compline,

      I plan to start with references. I'm at the point where I can use them, but don't totally understand them. I figure the pressure of having to explain them to a (small) class might push me over the edge. (one way or the other)

      I don't think I'll be able to teach anyone how to write objects, but I do want my students at least to be aware that they exist, know them when they see them, and be able to start to use pre-written modules like CGI

      Ignorance with Confidence
      oops in the non-oops sense...I forgot that I hadn't posted the reference page I wrote...and now have the wrong disk at work..That will be up tomorrow. I did write it though and planned on starting there. Ignorance with Confidence
Re: Perl High School Graduation
by jarich (Curate) on May 20, 2002 at 05:39 UTC
    Comments on your OO page, some nit-picky:
    • Explain references first. Starting with OO and then saying, oh, they're just references, won't help. References are difficult. Perhaps make them an entirely separate lesson (and remember, complex references usually turn out to be the most useful
    • Explain why a hash reference is a good idea for an object. Why not an array ref? Are other references options? (yes, but discuss why we usually pick hashes).
    • You have to be more careful of case. For example you've written both this:
      my $pp=new ball("Ping-Pong");
      and this: the scalars $PP
    • Your very first new sub has no comments but is far from intuitive. Perhaps something more like:
      package ball; # things from here will be of the ball class # Makes a new ball object. sub new { # assign all my parameters my ($class, $name, $size) = @_; my $self = {}; # This will be our new object # Mark this hash ref as a "ball" object bless $self, $class; # do our initialization (add useful defaults) $self->{'name'} = $name || "unnamed"; $self->{'size'} = $size || 0; return $self; }
      is in order.
    • Your second new function is even more unwieldy. Comment and perhaps focus on shift less. (It might not be necessary if you use something like mine above)
    • All your subs below your second new function are out of alignment.

    I think that there's a lot that you're taking for granted about OO and Perl OO. As this is a draft that's fine, but you need to explain more. pjf and I do Perl training courses that cover both references and Perl OO. Feel free to read over our course notes and see if there's anything there that can help you.

    I hope this helps.


Re: Perl High School Graduation
by Biker (Priest) on May 20, 2002 at 07:22 UTC

    Two things concerning "objects":

    1. It's difficult to grasp Object Oriented Programming (OOP) unless you have a good understanding of Object Oriented Design (OOD). I'd recommend starting by studying OOD. There are lots of good sources, both in books and most likely also on the 'Net. Once OOD is understood, OOP will become no more than an implementation, almost a question of syntax.
    2. You should probably know the subject in-depth before giving classes. But of course, that's your own decision. You know your own capabilities in teaching subjects you don't really master a lot better than I do. It was just a thought.

    Everything went worng, just as foreseen.

      Wrestling with Java has been useful for me trying to understand what the basic ideas are. As I teach Cad, general computer stuff, Perl, am Webmaster, computer fixing slave etc. I'd have to wait a long time to fully master the subject. One of the things I have found out about teaching, your students may or may not learn what you are teaching, but you most certainly will.

      Or, at the very least it will make my ignorance public. I've done that a time or two already</p

Re: Perl High School Graduation
by rinceWind (Monsignor) on May 20, 2002 at 09:57 UTC
    I agree totally with Zaxo here. References are very important, and should be done first, and in a great deal of detail.

    This is the order in which I would attempt explaining references:

    • Argument passing and returning. Passing a list, and returning a list.
    • Passing modifiable variables (pass by reference).
    • Passing and returning whole arrays and hashes by reference.
    • Anonymous arrays and hashes.
    • Multi-dimensional arrays.
    • Arrays of hashes, hashes of hashes, hashes of arrays.
    • Introduce polymorphism and reflection - the ref function.
    • Data::Dumper
    • Plenty of exercises on references, then students should be ready for tackling perl objects and classes.


      I feel another question coming on...Let me see if I understand the things you mention

      • argument passing as in passing arguments to subroutines?
      • Is pass by reference the same thing as passing a reference to a subroutine? I'm not clear on the exact meaning
      • ok with the next few. But what does Data::Dumper do?
        argument passing as in passing arguments to subroutines?
        Absolutely. Make sure that the students understand that they pass a list and can optionally return a list. Explain about the flattening effect of &foo(@a,@b); and explain that they are about to see a way of passing the arrays separately. If you have any advanced students, explain about wantarray.
        Is pass by reference the same thing as passing a reference to a subroutine?
        I take it you mean (passing a reference) to a subroutine, not passing a (reference to a subroutine). If so, yes, indeed. This is the same as in the C language - except that in C you are dealing with pointers (real addresses), whereas perl has references which essentially do the same job.

        Pass by reference: In the calling code, you have a real scalar (or array or hash) e.g. @foo. You pass a reference to it

        Now the code inside mumble can modify elements inside @foo:
        sub mumble { my ($bar) = @_; ... $bar->[1]++; #increments second member of array }
        But what does Data::Dumper do?
        Data::Dumper is a useful module that reverse engineers perl data structures into human readable perl code. To reconstruct the data structures, this can be done with an eval - this is one of many ways to do persistence in Perl.

        Further reading: perldoc perlsub gives more on subroutines and parameter passing. The Camel book: "Programming Perl" is an invaluable reference. Also, Sriram Srivanam's "Advanced Perl Programming" has an excellent chapter on references.

Re: Perl High School Graduation
by Molt (Chaplain) on May 20, 2002 at 10:25 UTC

    I would recommend you strengthened your own grasp of OO-Perl before teaching it. My own OO-Perl knowledge was pretty much gleaned from just two books, Programming Perl (I learnt from 2nd, but having read 3rd wished it was around then), and then Damian Conway's 'Object Oriented Perl'

    Unsure about high school-level, it's been a while, but by judiciously loaning this book to people I seem to have inspired a few others to learn OO-Perl fairly well. I know too that when I was being asked questions about it by them then I was able to remember enough of the book to show them where it was in there, and also to talk them through it with my own descriptive commentry.

    Having a copy of these (And probably 'Elements of Perl' too) to show to any of the class who seem to be chomping at the bit to get more Perl would probably be a good thing, would help them see what the more-respected books are like and so avoid the less useful 'The Complete Idiots Reference To Teaching Themselves PERL CGI In Sixteen Seconds' books.

    Feel free to point them at Perlmonks too, although warn them that you'll be peering at things to make sure they don't ask us to do their homework :)

Re: Perl High School Graduation
by Flame (Deacon) on May 20, 2002 at 02:16 UTC
    I'd take a look at devshed If I remember correctally, they had a good explanation of OOP.

    "Weird things happen, get used to it."

    Flame ~ Lead Programmer: GMS

      Precisely: here

      "Weird things happen, get used to it."

      Flame ~ Lead Programmer: GMS

      Thanks. Ignorance with Confidence
Re: Perl High School Graduation
by CharlesClarkson (Curate) on May 20, 2002 at 12:05 UTC
    I'd like to leave them with a taste of things to come without losing them.

    Perhaps you shouldn't use perl to explain it at all.

    Ask them to create a Person. Ask for typical characteristics of a person. Let them have some fun with it. Write the answers on the board.

    Ask for actions most people do. Write those on the board. Now turn to the class one more time and ask for two volunteers. We'll pick Mary and Bob. Tell Bob he is a person (even if you're not sure). Write "Bob is a Person" on the board. Do the same for Mary.

    You could mention that Person is an object. Feel your audience out and introduce OO terminology accordingly. Leave them with the excitement of explaining the world as objects containing objects containing objects containing objects . . .

    Charles K. Clarkson
    Clarkson Energy Homes, Inc.

      You have the right idea, but I might use an elevator instead of person. Otherwise you might end up with "Bob is a fat person" written on the board and poor Bob crying in the corner.

      I would argue that you don't need to teach OOP yet. Start with OOD and considering it is already May 20 and the students probably have some sort of last program to work on and study for thier final, don't push them too far. OOP can be hard to pick up on at first. The ideas behind it are very easy, but the programming may not be at this point.

        I think you are right there. I don't want them to be able to write classes yet, just know what they are and be able to use existing modules. Doing that for real would be a good second semester.
Re: Perl High School Graduation
by thunders (Priest) on May 20, 2002 at 15:43 UTC
    A few comments on your curriculum in general. It looks like you may come from a C/C++ back ground or that perhaps you are using perl as a C primer.
    One thing that's a pet peeve of mine is the C-style for loop, when it is not necessary.
    is more idomatically written as
    But that's just nitpicking, one thing i saw that I would definately recommend against is assigning file contents to arrays. It's better to process files in real time line by line especially for large files. That way perl doesn't have to keep track of (dozens||hundreds||thousands) of array elements.
    @lines = <FILE>#potentially expensive #a bit better while(my $line = <FILE>){ chomp $line; something with $line }
    Hope you find some of these comments useful, overall I would say that your course looks great, and that you seem to be commited to teaching Perl over PERL. And that's always good to see. Perl's object oriented features are best introduced through modules. I would focus on using CGI, DBI, LWP, Tk, the HTML::Parser series. For beginner and even advanced Perl Programmers being able to effectively use existing modules is a necessity.
    Show how modules are useful first, and make sure the students understand subroutines, references and hashes inside out. You may want to leave the details of OOP for an advanced class. An excellent, but challenging textbook for this is Damian Conway's Object Oriented Perl.

      Never touched the stuff (C or C+). Learning Java though. I'm trying (maybe not too well) to teach Perl as Perl to the degree I understand it. At the same time, I want the students to have a grasp of general programming constructs that apply to other languages

      You are right about the other points, though. Although I like being able to toss an entire file into an array, it could bog things down.

      My class has used the CGI and LWP::simple modules, but not in OOP style. I'm demonstrating Tk. I'm not silly enough to think beginners will be able to leave my class and write Perl objects. Or understand them. They need to be able to at least recognize things like my $button=$mainwindow->new(); and know that there is an object being made from a module. I'll be happy if they get that far.

Re: Perl High School Graduation
by agentv (Friar) on May 20, 2002 at 23:09 UTC
    ...I'm glad you asked this, because I had to wrestle with the very same issues when I wrote the chapter on OO Perl for the Sun course for employees.

    I decided that you need to give them a foundation in references first (and that does merit an entire chapter of its own) But my motivation for giving them references was this. Data in real life very seldom complies with our orderly ideas of arrays and hashes. In order to create data constructs that model our real-world things, we have to find a way to represent these irregularly shaped real-world things with a combination of scalars, hashes and arrays.

    Perhaps you might ask them to imagine defining the school as a set of departments (each of which has a name), each department owning some set of classrooms (each of which has a name), and in each classroom there are 20 resources (which may be referenced by their position). One conclusion that they might reach ('specially if you help them a little) would be to build a hash of hashes of arrays.

    Another good motivation to use references surrounds the problem of passing a group of three arrays to a function, and wanting the function to know which elements belong to which original array. It's a little simpler to build the rationale for this Or you might ask them to think about how we might want to pass a function a scalar, then an array, then another scalar and another array.

    It's tough to get the syntax of references right when you first begin, so giving them some concrete examples will smooth the path, and get them accustomed to the syntax.

    Then, when we're ready for objects, I suggest that a synopsis of Object Oriented concepts is appropriate. I don't think you have to study OO concepts in depth before you teach them. But you should explain and summarize certain key concepts before you have them trying to design objects. (The person and elevator suggestions above are apt for this.)

    The concepts I would want to explain to students about to begin OO work would be these: classes, objects, instantiation, methods, accessors, constructors, encapsulation and inheritance. It should be possible to consider all of these concepts in one or two class sessions (presuming a 50 minute class).

    With references, and then OO concepts in hand, they are ready to tackle an OO design as soon as you explain one more thing to them. Packages.

    Good luck.


Re: Perl High School Graduation
by TGI (Parson) on May 21, 2002 at 04:15 UTC

    I've got to say, check out thedamian's book: Object Oriented Perl. It is amazing. One of the best Perl books I've seen. It will help you with clarifying several concepts in your page. Packages and Namespaces, the meanings of the words object, method, and class. It really helped me a lot, and a coworker who was struggling with complex datastructures and refs suddenly had an epiphany when she saw the excellent data structure diagrams. She is now happily writing OO code. I bet there is a review in the Reviews section.

    I also recommend Sun's OO tutorial info on their learning java site. I found the link: Object-Oriented Programming Concepts. An excellent document. And it's free.

    Good luck with the course. I hope this helps.

    TGI says moo

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://167752]
Approved by sm3g
Front-paged by rinceWind
[karlgoethebier]: Cojones! We need cojones!
[karlgoethebier]: Ouch! Permissions! We need permissions!
[BarApp]: I can not use modules. I gain temporary access and still can not use modules.
[Cosmic37]: ta erix - this szabo geezer is pretty cool methinks and he writes about undef but I cannot see instructions for redefining the record separator after having undefined it
[Corion]: $/ = "wahtever";
[Corion]: (it's a magic variable)
[karlgoethebier]: BarApp: whoami
[Cosmic37]: ok fankyou - I was wondering about that but thought there might be a redefine command or something; peachy

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (9)
As of 2017-06-29 16:45 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (672 votes). Check out past polls.