[[ Editor - This capture was graciously provided by Grumpy. I took the liberty
of editing his emotes so that the document read as third person singular to
match the others. I also cleaned up spurious characters in a few places. I
read the document through, so there is no chance meaning changed. I will leave
things alone rather than risk changing the meaning. These policies will apply
to the complete set. ]]

Descartes says: the basic format of these classes is as follows:
Descartes says: I give a lecture on some topic or another
Descartes says: then we discuss questions on it
Descartes says: then we discuss other unrelated questions you might
currently have
Descartes says: sound ok?
Frog nods
Firebird nods
Zaknaifen says: Fine with me.
Esse nods
Grumpy says: 8) me too
Descartes says: I think since we have a different crowd here, I am going to
cover a lot of what I covered in the first class
Descartes says: that is the basic layout of the mud and how inheritance
basically works
Zaknaifen seems to disappear.
Descartes says: primary to the entire concept of behind LPC is the concept
of an object
Descartes says: have any of you ever done object oriented programming?
Grumpy nods
A shadow shakes his head
Grumpy says: a bit
Firebird nods
Esse says: no
Descartes says: well, LPC is what is called an object oriented programming
language
Descartes says: basically, that means that LPC has a few characteristics a
language must have in order to be considered object oriented (which I will
refer to as OO)
Descartes says: and object oriented programming I will refer to as OOP
Descartes says: the idea behind OOP is that you can write some code in 1
and only 1 place yet have many different programs use it at the same time
Descartes says: more important is why those things share this code
Descartes says: take for example, biology
Descartes says: in biology, living things are classed based on common
traits:
Descartes says: all humans are primates which are mammals which are animals
which are living things
Descartes says: all living things have a bunch of things in common like
reproduction and stuff
Descartes says: basically living things have a very generic set of things
in common
Descartes says: nothing really specific
Descartes says: then you have animals, which are living things, but differ
from plants in some very basic ways
Descartes says: similarly, mammals have most or all characteristics for
being an animal, but are different from other animals in important ways
Descartes says: do you understand what I am saying about that?
Esse nods
Firebird nods
Frog nods
Grumpy nods
A shadow nods
Esse says: This permits max. flexibility?  You can take a generic object and
provide it with subtle differences in turn making it a new object?
Descartes says: this relationship is called something like an "is a"
relationship
Descartes says: and it is central to being able to program effectively in
an OO language
Descartes says: in LPC, "is a" relationships are defined through an OO
feature called inheritance
Descartes says: more on that later
Descartes says: in programming, however, you have to decide what it is you
are coding
Descartes says: if you are coding a room type object, your room s a room
Descartes says: if you are coding a balrog, your balrog is a monster
Descartes says: if you are coding a sword, your sword is a weapon
Descartes says: and so on
Descartes says: in OOP, in a system such as this, you define a base set of
*objects*
Descartes says: and use these objects to create other objects which have
this "is a" relationship
Descartes says: in LPC, an *object* is any program which the game driver
has in memory
Descartes says: a file is NOT an object
Descartes says: files however are read in order to build objects
Descartes says: does that make sense?
Grumpy says: sorta
Grumpy says: the last part went a bit over me
A shadow nods
Frog says: "load" sort of turns a file into an object?
Descartes says: ok... then I will back up a sec
Firebird says: yup.
Descartes at Frog
Descartes says: you write these programs into files, whatever the programs
actually are
Frog says: *file* is stored on hard disk...*object* is held in memory.
Descartes at Frog
Descartes says: so say I write a room
Descartes says: it is, as frog said, a file stored on hard disk
Descartes says: utterly meaningless to the game
Descartes says: certain things in the course of a game tell the driver to
read that file and compile it into an object
Descartes says: for example
Descartes says: if you type update workroom.c
Grumpy nods
Grumpy says: i get it
Descartes says: that tells the driver to load your file workroom.c into
memory as an object
Descartes says: well, here is an interesting part
Descartes says: you can then type rm workroom.c
Descartes says: the file will cease to exist, but the object will still
exist
Firebird says: as long as it is in memory ?
Descartes at Firebird
Firebird says: but the file is needed to rebuild the object, if it has been
removed from memory ?
Descartes says: right
Firebird says: yup, got it.
Descartes says: cool :)
Grumpy says: the driver periodically checks for the files?
Descartes says: we will go over the concept of a function later, but for
now just understand that it is something in an object that allows it to
change in certain ways
Grumpy says: and if it doesn't find the files it removes the object?
Descartes says: no
Descartes says: the driver has the objects in memory
Descartes says: it does not care about the files
Grumpy says: so it won't remove them till a reboot?
Descartes says: once an object is in memory, it does not care if a file
exists
Grumpy says: ahh i see
Descartes says: there is something called clean_up() that can also remove an
object from memory
Descartes says: but yes, it could stay in until reboot
You smile
Esse says: hmmmmm, lotta memory
Grumpy says: got it
Descartes says: any object is made up of variables (which are simple data)
Descartes at Esse
Descartes says: and functions which manipulate those variables
Esse nods
Descartes says: with Nightmare, there is one basic object that ALL other
objects have in common. it is called /std/clean_up.c
Descartes says: an analogy would be:
Descartes says: a monster is to clean_up as a primate is to living things
Descartes says: no matter whether you are a monster or a sword or a player
or a room or a vendor, you have to be able to remove yourself from memory
Descartes says: clean_up defines the function which remove an object from
memory
Descartes says: then you move up to /std/Object.c
Descartes says: Object.c inherits clean_up.c
Descartes says: that means that all the functions and data contained in
clean_up.c are ALSO contained in Object.c
Descartes says: you allow a new object to "inherit" the functionality of
another through the line "inherit whatever"
Descartes says: so if I have an object I call A
Descartes says: it has the line: int query_number() { return 1; }
Descartes says: and nothing else
Descartes says: then in object B:
Descartes says: inherit "A";
Descartes says: int query_b_number() { return 2; }
Descartes says: and nothing else
Descartes says: that means that object B has 2 functions
Descartes says: query_number() and query_b_number()
Descartes says: it gets query_number() by inheriting A
Descartes says: is this making sense?
Descartes says: this is really hard stuff to understand
A shadow nods
Frog says: example...bag.c inherits open and close from container.c?
Descartes says: and I do not really intend you fully understand everything
I am saying
Descartes says: actually, bag.c inherits that open and close from storage.c
Frog blushes
Descartes says: and storage gets the ability to contain things from container.c
You chuckle politely
Grumpy says: but same idea
Descartes says: but the idea behind what you were trying to say was right
Esse says: what if you inherit something which also inherits something,
will it inherit that first things functions and variables
Descartes says: right esse
Descartes says: so you can inherit a ton of other objects indirectly just
by inheriting one object
Descartes says: so let's look at a room...
Descartes says: everybody change to /std
/std:
Descartes says: I think it will help if you look at these things as I point
them out
Esse says: ok
Descartes says: more room.c and don't go past the first 20 lines
more room.c
--==** /std/room.c **==--

#include <std.h>
#include <rooms.h>
#include <move.h>

inherit CONTAINER;
inherit "/std/room/exits";
inherit "/std/room/items";
inherit "/std/room/senses";

private int reset_number;

void reset();
void reinitiate();
void SetShort(string str);
void SetLong(string str);
string GetShort();
string GetLong(string str);
string GetExtraLong();
int eventMove(mixed dest);
int GetResetNumber();

void create() {
    container::create();
    exits::create();
    items::create();
    senses::create();
    reset_number = 0;

Descartes says: you can see it alone inherits a bunch of gunk
Descartes says: room.c inherits 4 other objects
Frog says: i've seen it before, though.
Descartes says: /std/container.c
Descartes says: /std/room/exits.c
Descartes says: /std/room/items.c
Descartes says: /std/room/senses.c
Descartes says: container.c in turn inherits Object.c which inherits
clean_up.c
Descartes says: so room.c has all of the functionality of 6 other objects
Descartes says: 4 inherited directly
Descartes says: 2 indirectly through container.c
Esse says: but don't exits, and objects also inherit clean_up?
Descartes says: when you build a room, you in turn inherit ALL of this plus
stuff specially defined in room.c
Descartes says: no esse
Descartes says: there is nothing in the mud that makes another object
inherit clean_up.c
Grumpy says: what if an object inherited another object twice
Grumpy says: would that cause an error?
Descartes says: no
Descartes says: in a well designed driver, you could "virtually" inherit
two objects
Descartes says: meaning that in fact you only get one set of functions and
data
Grumpy nods
Descartes says: unfortunately MudOS does not have that feature
Descartes says: so in MudOS
Grumpy says: so it would just waste memory..
Descartes says: if I have object A which inherits B and C
Descartes says: and both B and C inherit D
Descartes says: then A has two copies of D
Descartes says: right grumpy
Descartes says: it is a complete waste of memory, for the most part
Descartes says: there are rare instances in which you might want to do
that... but not in general
Descartes says: exits.c is naturally the object which defines the ability
to add exits from aa room as well as give the commands for exiting
Descartes says: can anyone guess why it is not in room.c itself?
Esse says: because the room could not then be a container?
A shadow shakes his head
Grumpy says: objects might want to inherit as well?
Descartes says: no.. room can be a container with or without the exits
defined in it
Descartes says: right grumpy
Descartes says: theoretically you could have an object on the mud which is
not a room yet needs exits
Descartes says: I have yet to encounter such an instance, but it is
possible
Esse says: like a large sack with a hole in it;)
Frog says: a rowboat.
Descartes at Frog
Descartes at Esse
Descartes says: if you could enter the sack
Descartes says: items holds the functions which define functions like
SetItems(), AddItem(), etc
Descartes says: senses.c SetSmell() SetListen() SetSearch(), etc
Descartes says: exits.c SetExits() AddExits(), etc.
Descartes says: then room.c is basically a tiny file which puts all these
things together and has extra stuff for describing the room :)\
Descartes says: note how the file room.c varies greatly from the object
room.c
Descartes says: room.c is a teeny file
Descartes says: it does not have much in it other than a couple of inherit
lines
Descartes says: and a couple of other functions
Descartes says: the *object* room.c, on the other hand
Descartes says: it is a big object :)
Descartes says: not as big as a player, but still big
Descartes says: that is because it has all the functionality of 6 other
objects
Grumpy nods
Descartes says: everyone feeling comfortable with what I have said to this
point?
Grumpy says: yep
Descartes says: I have only one more thing I want to discuss before we get
on to discussing things
Descartes says: ok... the ::create() stuff :)
Descartes says: we have spent most of the time discussing the primary most
important aspect of OOP
Descartes says: that is inheritance
Descartes says: another is something called "polymorphism"
Descartes says: basically, take object A and B from a while back
Descartes says: instead of query_b_number() in B.c... lets call the
function query_number(), just like the function in A.c
Descartes says: when another object decides to call query_number() in B.c...
what do you think gets returned?
Descartes says: remember A returned 1 and B returned 2
Grumpy nods
Descartes says: so does B->query_number() return 1 or 2?
Grumpy says: 2?
Frog says: i'd guess 2
Esse says: 1?
Descartes says: it returns 2
Descartes says: this is because B redefined query_number(0
Esse frowns
Descartes says: A's query_number() never gets executed
Descartes says: if you all look again at room.c
Descartes says: you will notice it has a function called create()
Descartes says: and that create() function does some very important things
Descartes says: if those things are not done, the room does not work
Descartes says: when you write your room, you are redefining create()
Descartes says: so, unless you find away to call the create you are
redefining
Descartes says: the room will not work
Descartes says: you can call functions you are overriding by using the ::
operator
Descartes says: ::fun()ans csall fun() in the inherited object, not the 
current object
Grumpy says: ahhhh :)
Descartes says: ::create() in your room thus tells it to call create() in 
room.c
Descartes says: if you just put void create() { create(); blah... }
Descartes says: you would end up going in a circle :)
Descartes says: void create() { ::create(); blah... }
Descartes says: that says don't call my create(), call room's create
Descartes says: actually, it does not say call room's create... it says
call create() in the inherited object
Descartes says: which causes problems if you inherit more than one object
Descartes says: so... good coding practice would be to do:
Descartes says: room::create();
Descartes says: that says specifically call create() in the inherited
object known as room
A shadow nods brightly
Descartes says: in most cases that you will deal with
Descartes says: you will be inheriting one object
Descartes says: so the ambiguity is not problematic
Descartes says: but when you look at room.c, since it has 4 inherited
objects, it has to specify exactly what it means
Descartes says: did that all make sense?
Frog says: "::" is called a "scope resolution operator"...means refer to a
variable or function OUTSIDE the current file.
A shadow nods brightly
Grumpy nods
Firebird nods
Descartes says: inherited by is perhaps more accurate, but yep :)
Descartes says: so does everyone feel like they have a basic understanding
of what IO have discussed today?
Frog nods
A shadow nods brightly
Firebird nods
Descartes says: grumpy? esse?
Grumpy nods
Grumpy says: i'm fine :)
Esse says: I'm not totally familiar with the syntax of the functions though
Descartes says: I will go over that in a sec :)
Esse nods
Descartes says: any questions on what I discussed today first?
A shadow raises his eyebrows
Esse indicates no
A shadow says: Er yes.
Grumpy says: nope
Firebird shakes his head.
Descartes says: Zak?
A shadow says: You discussed how the file is turned into an object..
Descartes nods
A shadow says: Is there a way to turn an object loaded in memory without a
file, into a file?
Descartes says: no
Descartes says: basically what happens is this:
A shadow says: Or for that matter to view the code of the object in memory,
if it has no file.
Frog says: parser reads a file, turns it into a "tokenized" version?
Grumpy says: that'd have to be a memory dump
Descartes says: yeah frog... when a file is originally loaded into
memory...
Esse says: ok, in you example you could erase a a file and still have the
object, is there a way to turn an object back into a file?
A shadow says: Go on guys. I'm getting sick again..
Descartes says: the file is read and stored in a way the driver understands
and can execute
Descartes says: so it is not a two way street
Descartes says: cause there is no way to determine the original way in
which it was written
Descartes says: did that answer the question?
Frog nods
Grumpy nods
Firebird nods
Descartes says: esse?
Esse nods
Descartes says: ok... now other questions.. and I will start with Esse's
Descartes says: functions... there are 3 parts to a function...
Descartes says: the prototype... the definition... the call
Descartes says: the prototype is just a way to tell the driver what
arguments are being passed and what is being returned
Descartes says: it is in the form:
Descartes says: type name(parameter list);
Descartes says: example:
Descartes says: int query_number(int x);
Descartes says: that tells the driver:
Descartes says: you are going to define a function called query_number with
one argument which is an int and your function will return an int
Descartes says: 2) the definition
Descartes says: this is where you say what will happen when the function
gets called
Descartes says: you start defining a function by repeating the prototype
Descartes says: int query_number(int x) {
Descartes says: the { instead of the ; says you are defining the function
starting at that point
Descartes says: then the code inside the function determines what happens
Descartes says: then you close it with a }
Descartes says: 3) the call
Descartes says: the call is just a reference to that function  from inside
the definition of another function
Descartes says: in some other function you could do:
Descartes says: query_number(5);
Descartes says: or better yet:
Descartes says: x = query_number(5);
Descartes says: that means you are passing 5 to query_number and executing
it
Descartes says: and the return value is being assigned to x
Descartes says: have you had a chance to read the chapter in the basic
textbook on functions yet?
Grumpy nods
Grumpy says: i have
Esse says: not fully, but i will
Firebird nods
Frog nods
Descartes says: it will give a better explanation
Descartes says: more detail
Descartes says: what other questions do any of you have?
Grumpy says: related to what u said or a bit of..?
Descartes says: any questions at all
Grumpy says: heartbeat() saw a post about it on the board..what does it do?
Descartes says: there is an efun called set_heart_beat()
Descartes says: which tells the driver either to call or stop calling a
function in that object called heart_beat() every 2 seconds or so
Descartes says: there is a lot of detail on that in the intermediate
textbook if you have not had a chance to read that yet
Grumpy says: ahhh like the drinking thing and chewing gum?
Descartes says: but that is the basic idea behind it
Grumpy says: no i haven't touched that..
Descartes says: not sure what you mean by those :)
Descartes says: but the heart_beat() in living things is what executes
combat
Grumpy says: well it makes u burp every minute or so
Descartes nods
Grumpy says: is that a heartbeat?
Esse says: ok, what if i want to start my workroom, where do i begin?
Descartes says: right
Descartes says: when drunk
Frog says: heat_beat not same as call_out, right?
Grumpy smiles
Descartes says: you have a small percent chance of doing something goofy
every heart beat
Descartes says: heart_beat() is similar but different from call_out()
Descartes says: heart_beat() is repetitive and you have no control over the
duration
Descartes says: call_out() is one time only and you control the duration
Frog nods
Esse says: ok, lets pretend I fully understand everything that has been
said, If I want to code my work room how would I begin?
Descartes says: I would suggest you simply copy someone else's and play
with substituting different things
Descartes says: that way you can see what changes and what remains the same
Descartes says: but most important:
Descartes says: 1) read the beginning textbook
Descartes says: 2) read the rooms tutorial
Descartes says: I have been aiming the classes to be used in combination
with reading those things
Esse nods
Descartes says: what other questions are bothering you all?
Firebird nods
Frog says: what exactly does "clone" do?
Firebird says: are you teacher by profession ? :-)
Grumpy says: have nothing right now
Grumpy falls down laughing
Descartes says: 1) Firebird no :)
Descartes says: 2) clone:
Descartes says: clone looks for something called a master copy of an object
and makes an exact copy of it
Descartes says: for example:
Descartes says: I have ob = new("std/monster");
Descartes says: if there is no object called "/std/monster"
Descartes says: then one is loaded into memory
Descartes says: that one becomes the master copy
Descartes says: then...
Descartes says: that object is copied
Esse says: ok assuming that inherit causes a kind of hierarchy in coding
where specific things call on more fundamental things, like room calls on
container which calls on clean_up?  As far as law is concerned which can we
modify?, for example can
Descartes says: one sec esse :)
Esse says: er
Descartes says: then the copied object is given the name /std/monster#001
or something like that
Descartes says: and that object is assigned to the variable ob
Descartes says: the master copy is always used to make new monsters
Descartes says: did that answer your question frog?
Frog nods
Esse says: it answered mine also
Descartes says: oh :)
Descartes says: in general....
Descartes says: it is better to clone and configure than inherit
Descartes says: for example:
Esse says: is
Descartes says: there are a few hundred object cloning /std/monster
Descartes says: for which there is one master object
Descartes says: if you write a monster object which inherits monster.c
Descartes says: you will be creating yet another master copy for that
special object AND the actual used copy
Descartes says: so that is 2 objects for just one monster where 1 object
was needed
Descartes says: which wastes RAM
Descartes says: of course
Descartes says: if you have more than one of that monster in your area or
it does special things, then inheritance is necessary
Esse says: what about when things inherit clean_up?
Descartes says: every 1/2 hour or so...
Descartes says: the driver looks for objects which have not been "touched"
in the game
Esse says: is that redundant though?
Frog says: in my area...better to clone room.c rather than inherit room.c?
Descartes says: it then calls something called clean_up() in that object
Descartes says: err, no, not with room.c frog
Frog says: whew.
Descartes says: you are actually using the master copy to do things with
rooms
Descartes says: you never clone a room :)
Descartes says: but about clean_up()...
Descartes says: the clean_up() function then gives the object a chance to
remove itself from memory
Descartes says: the object is the end decider of whether it gets deleted
Descartes says: it can also tell the driver to bugger off and never call
clean_up() in it again
Descartes says: did that answer your question esse?
Esse says: is clean_up then the thing which removes link dead characters?
Descartes says: no
Firebird says: especially link-dead ghosts.:-)
Descartes says: I do something different to remove link_dead characters
Descartes says: though it could be used to do that
Esse says: yes actually, i guess in some cases cloning can't take place 
because inheriting is necessary
Grumpy says: so is it better to clone monsters?
Descartes says: any other questions?
Frog shakes his head
Descartes says: in general it is better to clone monsters
Descartes says: but sometimes it is impractical :)
Grumpy says: i mean say i have 5 goblin guards
Grumpy says: i create a master and i clone the rest
Descartes says: then in that case it is better to inherit and clone that 5
times
Grumpy nods
Grumpy says: where would u put clone?
Grumpy says: in the room.c file?
Descartes says: clone is done from reset
Descartes at Grumpy
Descartes says: you always actually clone a monster
Descartes says: the question is whether you are cloning /std/monster.c or
your own version
Grumpy nods
Esse says: how do we discover all the things we can clone and inherit?
Descartes says: reading /doc/build and coming to my classes :)
Frog says: when is next class?
Descartes says: next class I will be discussing details of room building
Descartes says: Wed 7pm
Descartes says: this class was a bunch of nastiness
Firebird says: that is in the midst of night here..:-)
Descartes says: but getting it out of the way will help you get a faster
grip on things later
Esse says: can i have a transcrip? I work on Weds.
Firebird says: looks like I'll have to get a copy of that session then.
Descartes says: that's why I have sat and wed classes :)
Grumpy says: i did it the copy except for the little bit i was out
Descartes says: I may change sat classes to noon always
Descartes says: you missed nothing grumpy :)
Esse says: that is a good time
Firebird says: yup.
Grumpy nods
Frog says: sat noon is kewl with me.
Esse says: room tutorial and beginning text is in which sub-dir?
Firebird says: could we have a special subdir for the class-scripts ?
Firebird says: so that we could re-read anytime we want ?
Descartes says: ok I gotta run :)
Esse says: bye
Descartes says: yes I will create a /doc  sub dir
Descartes says: grumpy please mail that to nialson
Grumpy nods