Introduction to object and "dot" notation: feedback wanted
I am busy writing lessons for rur-ple (I noticed it's been kindly
mentioned here recently) and thought, in spite of the "flack"
following the request received by some of you for a book review ;-) ,
that I would ask for feedback about an introduction I have written to
OOP and the "dot" notation.
[I am *not* planning to ask feedbacks on all the lessons ;-)]
Context 1. The set-up of rur-ple is a world in which a robot can be
made to accomplish certain tasks. Initially, the "function-based"
approach is used to instruct the robot to do its stuff. For example,
a simple program might be as follows:
if next_to_a_beeper(): pick_beeper
Context 2. The preceding lessons would have covered python data
types, variables, functions, and most python keywords, all used in the
context of the robot world or at the interpreter.
And now... here's the lesson which you are welcome to trash,
criticize, shoot down in flames or ignore!
P.S. html formatting rudely removed from what follows...
__Object-Oriented Programming: "dot" notation__
We are going to learn about a modern programming style called
Object-Oriented Programming [OOP]. Before we start writing, we will
first learn how to read and understand the notation used.
__All in a dog's day__
Fido is a dog. During a typical day, he does various actions: he eats,
runs, sleeps, etc. Here's how an object-oriented programmer might
In addition, Fido has various qualities or attributes. He is tall (for
a dog) and his hair is black. Here's how the programmer might write
the same things.
Fido.size = "tall"
Fido.hair_colour = "black"
In the object-oriented language, we have the following:
= Dog is an example of a class (of objects).
= Fido is an instance (or particular object) in the Dog class.
= eats(), runs() and sleeps() are methods of the Dog class; 'methods'
are essentially like 'functions' which we saw before (the only
difference is that they belong in a given class/instance).
= size and hair_colour are attributes of a given instance/object
= Objects can also have other objects that belong to them, each with
their own methods or attributes:
We'll see how this works later. For now, let's see how Reeborg can use
the "dot" notation.
__A used robot get his name__
So far, all the programs we wrote instructing Reeborg to accomplish
tasks have been written without using the Object-Oriented Programming
(OOP) notation. Let's start with a simple example.
First, we start by having an empty world, removing the robot if needed
by pressing the add/remove robot button
Now, you might remember that RUR in RUR-PLE stands for: Roberge's
*Used Robot*; the robots we use are old and faulty. [We will learn how
to fix them later.] So, we will create our first instance of the
UsedRobot class and name it, appropriately, Reeborg! We will then
instruct it to take one step and then turn itself off.
Just like functions can have arguments, methods can too. Start with an
empty world and try the following:
# add robot at origin [by default], but with more interesting colour
Larry = UsedRobot(colour='blue')
# second robot, default colour (grey) facing North
Curly = UsedRobot(1, 3, 'N')
# Third robot carries beepers
Moe = UsedRobot(1, 2, beepers=9, colour='yellow')
.for i in range(3):
# Turning off any one robot ends the program
Robots come in a variety of colours: grey (by default), yellow, blue,
light blue, green and purple. They can be positioned anywhere in the
world (with more than one robot at the same intersection), face any of
the four directions ('E' [by default], 'N', 'S', 'W') or carry a
number of beepers from the start. Note that there are two named
arguments (beepers and colour) and three unnamed ones (street, avenue
and orientation). The two named arguments must appear last (their
order may be interchanged); the three unnamed arguments, if they
appear, must appear in the same order. Thus, if we want to specify an
orientation (say 'N'), we must first specify a street and an avenue so
that the orientation is the third argument.
The following are allowed declarations:
R1 = UsedRobot(2) # created at 2nd street, 1st avenue, facing East
R2 = UsedRobot(2, 3) # 2nd street, 3rd avenue, facing East
R3 = UsedRobot(3, 1, 'S') # 3rd steet, 1st avenue, facing South
R4 = UsedRobot(5, colour='yellow') # 5th street, 1st avenue, facing East
The following declarations are not allowed:
R5 = UsedRobot(3, 'S') # orientation is not 3rd argument
R6 = UsedRobot(colour='yellow', 5) # unnamed argument listed after named one
Re: Introduction to object and "dot" notation: feedback wanted
Just a quick note of approval re use of Dog class. You might want to lowercase fido, or not. I'm used to reserving capitals for the class definition, keeping all instances lower, but of course there's nothing much beyond taste to influence such decisions about style.
Perhaps more should be included in standard CS readings about coding style in general -- like, some coders prefer variable width fonts in their text editor, whereas I'm an old school fixed width coder.
Plus I support your approach of focusing on dot notation as a critical step (my approach as well).
I favor a first pass using existing Python objects, already dot-ready (e.g. lists and dictionaries), then an interlude defining functions, using the learned collection types, then back to dot notation again, but this time rolling your own classes (with metaclasses in some future pass).
Re: Introduction to object and "dot" notation: feedback wanted
On 1/18/06, kirby urner <[hidden email]> wrote:
> Just a quick note of approval re use of Dog class. You might want to
> lowercase fido, or not. I'm used to reserving capitals for the class
> definition, keeping all instances lower, but of course there's nothing much
> beyond taste to influence such decisions about style.
I thought about doing that ... but, then I thought I had been talking
about Reeborg (with a capital letter) all the time that it would look
artificial to suddenly use a lowercase letter. At the very least I
could put a note about the standard convention ... but I wonder if
this would be seen more as a distraction at this stage...(me
ambivalent?... maybe I am...)
> Plus I support your approach of focusing on dot notation as a critical step
> (my approach as well).
I realised after reading the lesson I wrote that I never explained in
words about how the "dot" connected an attribute/method to an instance
- I just showed it. Should I repeat it in words?
> I favor a first pass using existing Python objects, already dot-ready (e.g.
> lists and dictionaries), then an interlude defining functions, using the
> learned collection types, then back to dot notation again, but this time
> rolling your own classes (with metaclasses in some future pass).
Good idea... I have not written the lesson about lists (or any other
sequences yet) and just realised that I will have to introduce the dot
notation then (to show, at the very least, how to append items to a
list.) Perhaps I can modify your usual approach: introduce the dot
notation earlier (pretty much with the lesson I submitted for
comments) but with a mention that we will learn more about classes
later. Then, in the lesson immediately following it, introduce lists
AND lists methods. As for functions... The way rur-ple is structured,
the first Python keyword introduced is "def" to define new functions
in the robot world. Then it's if, else, elif, pass, not, while, ...
all of this before even introducing numbers, strings and variables.
At 20:28 18/01/2006, Andre Roberge wrote:
I have a query about this call. The way the left_front_paw moves is
not going to be very different from right_front_paw or the back
paws. Now if it's identical, in a simplified model, does not
make more sense? It is harder to understand, and I'm not happy with
the argument to the method, but it promotes code reuse.
In the beginning was the word,
and the word was Content-type: text/plain.
> At 20:28 18/01/2006, Andre Roberge wrote:
> I have a query about this call. The way the left_front_paw moves is
> not going to be very different from right_front_paw or the back
> paws. Now if it's identical, in a simplified model, does not
> make more sense? It is harder to understand, and I'm not happy with
> the argument to the method, but it promotes code reuse.
Since this is intended to be the first introduction to the dot
notation, I think it would be a bit more confusing then necessary.
What I want to illustrate is the "chaining" that can occur with using
the dot notation. It is more the notation, than the underlying
implementation that I want to introduce at this point.
In term of promoting code reuse, my first inclination would be to have
Fido.left_front_paw = Paw() # Paw() is a class, with a move() method
Fido.right_front_paw = Paw()
instead of having a method argument.
[One might argue that Fido.move() has to imply that each individual
paws must move, hence your observation about having it as a method
argument instead ... hmmmm... ]
I'll have to think about it further and I thank you for your suggestions.