Object oriented languages distinguish between a blueprint, which defines the generic aspects of a whole class of objects, such as houses or fish, and the special case instances of that blueprint, the specific houses or fish, each occupying its own time and place, taking up room in memory.
:: slide 1 ::Above is some code for a generic Animal.
The blueprint defines only two behaviors, one for giving birth to an instance of itself (__init__), and another for representing itself to the public (__repr__).
There's an attribute called species which will get assigned a random value, choosing from the list [ 'Dog', 'Monkey', 'Philosopher', 'Bird' ] as the four possibilities.
For now, the species is unspecified.
Because the philosopher Descartes famously said cogito ergo sum (I think therefore I am), the logician writing this code chose the name cogito within the birth method, and me within the representation method (because they're roughly synonymous).
Those of you who already know Python will agree this is somewhat pathological, but does serve to illustrate the positional nature of this handle to the specific instance, more traditionally and consistently called self across all methods.
:: slide 2 ::What you see above is not another blueprint, but a function. In this particular brand of logic, the level of indentation is significant. The function begins with the orange signifier def, and ends with the return statement.
The many function "eats" two arguments (the parentheses are like a mouth turned sideways -- think of emoticons). It expects to know howmany, and what species.
These two parameters are like guards at the castle gates, or like butlers at the door, waiting for a hand-off, for incoming values, which they'll circulate internally to said function.
In the code below, this function many is invoked three times, each time to fill a zoo_cage with additional animals. The extend and append methods, both used in this code, are built in to each list instance, thanks to the blueprint for the list type.
"Dot notation" of the form "noun.verb(arguments)" and "noun.adjective" is what we use to interact with our blueprints and instances.
The equal sign ("=") is an assignment operator in this Logic and is used to bind names to objects in memory. Other symbols are used to compare values for equality ("==") or to test whether two names actually specify the same object ("is").
:: slide 3 ::Secondary characteristics of color and sex get added after the zoo_cage is already full with our full complement of instances. They're set for each animal individually, irrespective of the fact that neither quality was mentioned at the blueprint level. Not every brand of object oriented logic has such a liberal (forgiving) grammar.
Note that if you trigger the representation method (__repr__) before color and sex attributes have been assigned some values, you will get an error message, as the returned self description is counting on having that information available, even if the sex is "unknown".
The choice function, imported from the random module, is not obligated to choose uniquely, only randomly. In other words, after some runs of this program, we might have only Monkeys, even all white ones, whereas other times we might have a mix of Birds and Philosophers.
:: slide 4 ::What you see in the square brackets, denoting a list, is our zoo_cage of animals. Because of how the representation method was written, one sees the color and species, with the sex in parentheses.
Run this over and over to get a different mix of animals. Notice the shuffle function in Slide 3, also imported from random, keeps the animals in a jumble, instead of a sequence of Dogs, then Monkeys or whatever.
Comment out this line (with a #) and run the script again, to see what difference shuffle makes. You might see where we'd use it to shuffle a deck of cards, with both Deck and Card more blueprints for specific instances.
For further reading:
Trends in Early Mathematics Learning: Looking Beyond Y2K
More curriculum writing featuring Python
