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,
Zaxo

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

• 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");
  [download]

  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;
  }
  [download]

  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. http://www.perltraining.com.au/notes/

I hope this helps.

jarich

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.

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

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.

--rW

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

&mumble(\@foo);
[download]

Now the code inside mumble can modify elements inside @foo:

sub mumble {
    my ($bar) = @_;

    ...
    $bar->[1]++;   #increments second member of array
}
[download]

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.

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 :)

Precisely: here



---


"Weird things happen, get used to it."

Flame ~ Lead Programmer: GMS

Thanks. Ignorance with Confidence

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 . . .

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.

for($a=0;$a<10;$a++){...}
[download]

for(1..10){...}
[download]

@lines = <FILE>#potentially expensive

#a bit better
while(my $line = <FILE>){
    chomp $line;
    ...do something with $line
}
[download]

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.

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.

---v

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