[[ Editor - I took the liberty of editing this document to read as third
person singular to match the others. I also cleaned up spurious characters in
a few places. I read the document through, and was present at the class 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 <cre> anyone here for the class come to my workroom :)
Descartes says: thought there would be more than just y'all, but oh well :)
Kahless says: I've been here before. I remember being very nervous.. :)
Kahless polishes an apple and sets it on Descartes' desk.
Descartes says: the way I want to do the classes is to sorta lecture on a
topic... actually more discuss than lecture
Descartes says: then once the topic has been covered we can go over individual
poirts of interest
Kahless nods.
Descartes says: but today will be a sort of beginning, discussing how
everything here works together in general
Nialson says: You'll prob get more attendence if you post the topics in 
advance, people will think more about it.
Descartes says: having a basic idea of the big picture can help you figure out
a lot of little small problems in the lng run
Descartes smiles.
Descartes nods.
Kahless says: That's what I need, I think. The basics.
Descartes nods.
Descartes says: do both of you understand fully what the driver does and what
the mudlib does?
Kahless says: I can't say fully, no. I have a general idea.
Kahless says: What I've read in the docs.
Descartes says: ok :)
Nialson says: I believe I do, but I'm here to pick up what I might have missed.
Descartes says: well... the driver is a C program
Descartes says: it's function is to listen to the mud port waiting for
incoming telnets
Descartes says: it also interprets LPC code
Descartes says: so the driver is not a game
Descartes says: it is really a sort of telnet daemon and language interpreter
rolled into one package
Descartes says: what you do with the driver is up to you... you malke use of
the driver by writing programs in LPC
Descartes says: not all people use it to write games
Descartes says: I could write user it to write a world wide web server if I
wanted
Kahless says: Pretty much anything a normal c program can do, in other words.
Descartes says: I could use the driver as an all aroudn network server
Descartes says: much easier, but much slower
Descartes says: it is pretty much overkill to use it to do any of those things
Descartes says: although I think the driver could be used to make a good
network interface
Descartes says: we use the driver, like most people, to write a game
Descartes says: the mudlib is the LPC code not in /d or /wizards
Descartes says: besides interpreting LPC code, the driver also interfaces with
the mudlib in two ways
Descartes says: 1) is through something called an apply
Descartes says: 2) through special functions called efuns
Descartes says: an apply is a special function in a LPC code which the driver
calls
Descartes says: create() is an apply, for example\
Descartes says: /doc/applies has a full list of applies
dir /doc/applies/
/doc/applies/:
   1 README      c/          i/          p/          v/     
   1 __INIT      d/          l/          q/          w/     
     a/          e/          n/          r/     
A total of 2006 bytes in 2 files.  (12 directories)
m /doc/applies/README
--==** /doc/applies/README **==--

This directory contains documentation on driver applies.
An apply is a function in an object which exists to be called
by the driver.  When reading about an apply, keep in mind that
not all applies are used for all objects.  In particular, keep
in mind that there is a special subset of applies called master applies
which are functions existing solely in the master object to be
called by the driver.  If the functions exist in other objects, they are
treated as normal functions.
In order to work with the "man" command, all applies are kept in 
sub-directories based on the first letter in their name.  Excepting, of
course, the apply __INIT().

See the credits documentation in /doc/etc for information on the authors
of these documents.

Descartes of Borg
940122
Descartes says: an efun is a function stored internally in the driver, written
in C
Descartes says: they are much faster than anything executed in LPC
Descartes says: a full list of efuns are in /doc/efun
dir /doc/efun
/doc/efun/:
   1 README      d/          h/          l/          p/          t/     
     a/          e/          i/          m/          q/          u/     
     b/          f/          j/          n/          r/          v/     
     c/          g/          k/          o/          s/          w/     
A total of 442 bytes in 1 file.  (23 directories)
m /doc/efun/README
--==** /doc/efun/README **==--

The documentation in this directory is simply the ascii man pages
for MudOS 0.9.19 efuns which ship with the driver.  They are
setup within the Nightmare mudlib 3.2 to be accessible through a
"man" command.  In addition, SimulEfun, lfun, and apply information
may be accessed through the man command.

Credits for the documentation of the efuns in this directory may be
found in the file /doc/etc/Credits.DriverDocs

Descartes of borg 940122
Descartes says: you can call these efuns from anywhere in your code
Descartes says: treat them just like functiosn you defined, except you do not
have to define them :)
Descartes says: do you understand what all the driver is doing to the mud?
Kahless says: I sometimes have trouble locating efuns and the like. I'd
assumed that some of them weren't listed.
Descartes says: they are all listed :)
Kahless says: And yes, I have a fairly good idea.
Descartes says: however, there is a way of simulating efuns
Descartes says: these are called simulefuns
Descartes says: and they are not quite fully documented in /doc/SimulEfuns
Descartes says: more on those later though
Descartes says: the mudlib itself is divided up into directories based on
functionality and security
Descartes says: /adm is called the secure directory
Descartes says: files central to the operation of the mud are kept there, as
well as any objects which need tspecial access
Descartes says: /cmds naturally are commands :)
Descartes says: /d are domains... creator areas are built off of domains
Descartes says: /daemon is where daemons are kept... don;t worry what a daemon
is just yet :)
Descartes says: other than it is an object that has no environment
Descartes says: /doc is all documentaion about everything on the mud
Descartes says: /ftp of course is where you can transfer files
Descartes says: /hm is supposed to be where high mortal castles are kept :)
Descartes says: all logging is done to /log
Descartes says: news files are stored in /news\
Descartes says: then the most important directory to know about /std
Descartes says: all inheritable objects are kept in /std
Descartes says: any object which you write as a creator should at sme point
inherit an object from this diretory
Descartes says: I will discuss more oon why later
Descartes says: /tmp is a place for transferring files and such
Descartes says: /wizards are the wizard home dirs
Nialson says: Question: are you going to discuss changes to this later for version 4?
Descartes nods.
Descartes says: the basic directory structure will only change insofar as
/wizards will become /realms
Descartes says: and /d /domains
Descartes says: I am trying to erase the word wizard from the mudlib
Descartes says: a program will convert all old files :)
Descartes says: as a creator, you should pretty much concentrate on
understanding what is in /std
Kahless says: Is there a definable reason why areas can't be attached directly
to d/standard?
Kahless says: Not to change the subject.
Descartes says: at any rate :)
Descartes says: a domain is meant to define a theme for a region
Descartes says: so Praxis is surrounded by regions called domains
Descartes says: which in turn are surrounded by areas
Descartes says: so only domains connect to standard :)
Descartes says: at any rate.. any questions so far?
Descartes says: ok... well... now time for some meat I suppose :)
Descartes says: central to coding in LPC is the concept of object oriented
programming
Descartes says: that sounds like big fancy stuff, but it is not
Descartes says: take for example the biology stuff
Descartes says: in the classification system, living things are either plants
or animals
Descartes says: they all have in common that they are alive
Descartes says: but they differ in every other way
Descartes says: similarly, mammals have all of the characteristics of animals,
which have all of the characteristics of living things
Descartes says: but they do not have many of the characteristics of reptiles
Descartes says: and so on
Descartes says: object oriented programming is based on this way of looking at
things
Descartes says: to create a human object
Descartes says: you would build aliving object first and give it all the
traits for living things
Descartes says: this living object would be shared by plants and animals to
define what it takes to be living
Descartes says: however, you would have yet another objecty called the animal
object
Descartes says: it would have all the functionality of living objects, plus
functionality which makes it unique
Descartes says: this is called an "is a" relationship
Descartes says: where object c is an object b is an object a
Descartes says: in LPC programming, functionality is stored in functins, and
properties in variables
Descartes says: central to all mud objects is /std/clean_up.c
Descartes says: it contains basic functionality all objects should have
Descartes says: this basically is the clean_up() apply
Descartes says: plus some other base functionality
Descartes says: in LPC, the main tool of OO programming is inheritance
Descartes says: this is mostly because LPC is not fully object oriented
Descartes says: for pure object oriented programming, you need 4 things:
Descartes says: 1) Inheritance
Descartes says: 2) Data abstraction
Descartes says: 3) Polymorphism
Descartes says: 4) Encapsulation
Descartes says: LPC fully has 1 and 4, and sorta allows 2 and 3 in a backass
manner
Descartes says: inheritance:
Descartes says: this is the ability to create a new object which "inherits"
the functionality of another
Descartes says: 2) data abstraction is the ability to effectively create new
data types
Descartes says: this is the pmost poorly supported part in LPC
Edison says: it's supported if you don't mind an over-head of 100 bytes per
instance of an abstract type
Edison <cre> an object can be an abstract data type if you don't mind the 119
byte over-head that each MudOsS object requires, not including entires in the
object name hash table
Descartes <cre> yes, which means it sucks for data abstraction :)
Descartes says: '3) polymnorphism is the ability to have the same function
perform many different functions depending on circumstance
Descartes says: this is supported through passing data of mixed type to
functions and acting dependedt on the type
Descartes says: which is not true polymorphism
Descartes says: 4) Data encapsulation... very important
Descartes says: this means that data stored in an object belongs to that
object
Descartes says: for exaample
Descartes says: you have a room
Descartes says: you have an int representing whether the room has been visited
or not
Descartes says: that int *belkongs* to the room object
Descartes says: no other object should be able to do anything to that variable
without the consent of the room object
Descartes says: so you have query_*() and set_*() which control the change of
value of that int
Descartes says: it is an interface to outside objects
Descartes says: this is oppsed to another object simply doing room->mY_int = 1;
Descartes says: instead, you have to do room->set_my_int(1);
Descartes says: and the room gets to decide if it in fact should change the
value of my_int
Descartes says: now that is all a lot of heavy nonsense
Descartes says: does it make some sense to you?
Kahless says: Actually I was just thinking that this is the first you've said
that threatens to go over my head.
Descartes says: don't worry... it is not meant to sink in now, but later
Kahless says: Good :)
Descartes says: so the first set of objects we will look at is the room,
Descartes says: I will give an overview of rooms, then we will quit :)
Descartes says: room contains several different types of functionality
Descartes says: at any rate, a room does tis these things:
Descartes says: 1) a place where people are (it contains people and objects)
Descartes says: 2) rooms have exits so the things can go other places
Descartes says: 3) rooms are a source of sensory input, places where you can
smell things, see things, hear things, and rummage around
Descartes says: the file /std/room.c contains all of this functionality
Descartes says: so when you are building a room
Descartes says: you are taking a generic room with all this functionality but
no individual character
Descartes says: and you are creatign data for it that gives it character
Descartes says: in the rooom files
Descartes says: the line /std/room.c allows you to have all functions defined
in /std/room.c callable by you
Descartes says: those functions now become part of your object
Descartes says: in addition to those functions, the functions of all obejcst
inherited by room itself
Descartes says: room inherits the folloing:
Descartes says: 1) the mud container object for container  fucntionality
Descartes says: /std/room/senses.c for sensory functionality
Descartes says: /std/room/items.c for item functionality
Descartes says: /std/room/exits.c to give exits to the room objects
Descartes says: do you understand what is going on when you inherit
/std/room.c
Kahless says: Yep
Descartes says: ok... well this is a good stiopping point I think, and a good
plave for you to bring up your own topics
Kahless ponders.
Kahless says: The problem I have usually is that questions come up in the
process of creation. I generally get them resolved, but It's hard to come up
with something now because I'm not running into specific problems.
"If a room is inherited from containers, is there a limit to what can be placed in a room?
Nialson says: If a room is inherited from containers, is there a limit to what can
be placed in a room?
> Descartes says: well... this is where polynorphism comes into place
Descartes says: in container.c a function called receive_objects() in the
receptor object is called whenever an object wants to move
Descartes says: this is where a container gets to say "no, you can't stick
that in me" :)
Descartes says: in most containers, this is where it checks how much they can
hold
Descartes says: rooms, of course do not want this kind of check
Descartes says: so in room.c, roomc. overrides receive_objects()
Descartes says: this means that you redefine what receive_objects() does
Descartes says: in the case of room.c, it is redefined to return 1 always
Descartes says: so, yes, you can make a limit
Descartes says: by overriding receive_objects()
Descartes says: but room.c itself has no limit
Descartes says: make sense?
Nialson says: is receive_objects() the best way to forbid say non-newbies from
entering newbieland?
Kahless says: You call the inhereted room in create, and override it in the
::create sectiooon
Descartes says: yes
Descartes says: actually that is backwards :)
Descartes says: by defining create()
Descartes says: you override the create() in room.c
Kahless says: But you only override those sets that you define?
Descartes says: the ::create() allows you to call that create() function
Nialson says: I wanted to find out what room an object was in regardless how
many bags it was in. I wound up taking the environment of the environment ...
of the object until I found an object that had no environment. was this a good
way to do it?
Descartes says: I am not sure I understand what you mean
Descartes says: Kahless... when you do SetLong() in the room, you are making
a function call, not overriding
Kahless says: And that call is apart from the basic room inhereted in the
inheret line?
Descartes says: your create() overrides create() in room.c
Descartes says: the ::create() call means call create() in the inherited
object
Descartes says: that call means call the topmost functin called SetLong()
Descartes says: by topmost, I mean if c inherits b inherits a
Descartes says: if you have SetLong() in b and a, b::SetLong()
Descartes says: b::SetLong() is the topmost :)
Descartes says: in the case of SetLong(), it is defined in Object.c
Descartes says: which is inherited by container which is inherited by room
Kahless says: I don't know why I'm having so much trouble with this concept.
It should be fairly simple.. :(
Descartes says: is that making sense?
Descartes says: it is not a simple concept
Kahless says: Perhaps a different allegory..
Descartes says: bicycles and trains and cars have wheels
Descartes says: they are all different sorts of things, but they have whells
Descartes says: and in many cases, those whells even do different things
Descartes says: for example, train wheels on a track, others on a road
Descartes says: so a mobile object might "inherit" a wheels object
Descartes says: wheels object would contain properties
Descartes says: like whell size, colour, etc
Descartes says: and it would contain functions which define what the wheel
does
Descartes says: the mobile object is in turn inherited by your file which is a
car object
Descartes says: so your car has wheels in virtue of the mobile object
Descartes says: but you make your cmobile object a car by doing certain
things:
Descartes says: you give it a long description saying it is a car
Descartes says: you give it some sort of occupant capacity, etc
Descartes says: this involves calling functions in the mobile object
Descartes says: SetLong() in the mobile object would set the variable "string
long", so that long equaled whatever you passed to SetLong()
Descartes says: then when something looked at the mobile object, it would see
what you set it to look like through GetLong()
Descartes says: that is making a function call
Kahless says: I'm particularly interested in how this allegory relates to the
create() versus ::create
Descartes says: getting there\
Kahless nods.
Descartes says: well, create is where you get to set up inital values for an
object
Descartes says: in create() in room.c
Descartes says: it does certain things which muist be done to make your room
work
Descartes says: when you write your own create() function
Descartes says: you are telling the driver to call what you wrote, not the
create() in room.c
Descartes says: yet your room will not work unless the stuff in the create()
in room.c is executed
Descartes says: so for example:
Descartes says: void create() { create(); } is an infinite loop
Descartes says: it says keep calling create over and over again
Descartes says: but void create() { ::create(); }
Descartes says: is not
Descartes says: it says call not this top level create, but the one in the
level underneath
Descartes says: so you can allow create() to do 2 things instead of one
Descartes says: thus polynorphism
Descartes says: does that help?
Kahless says: I think so.
Descartes smiles.
Descartes says: if you do create() { bl;ah vlah blah; }
Descartes says: the create() in room.c never gets called
Descartes says: so some vital things never happen
Kahless says: I guess what's confusing is the concept of one overriding the
other. Isn't it more in addition to, then?
Descartes says: I guess a good homwork assignment is too read room.c and the
files it inherits
Kahless says: I'll do that.
Descartes says: try to follow the flow of execution of the code
Descartes says: remembering that create() gets called when the room is first
loaded
Descartes says: init() when ever an object is moved to the same place as the
room
Descartes says: then you will have plenty of questions to ask next class :)
Kahless grins.
Kahless says: You got that right!
Kahless says: I'm gonna get all of this if it kills me :)
Descartes says: tiem to move nialson
Descartes dissolves into a borg transporter beam.
You are magically teleported somewhere.

/d/standard/freezer
The local freezer.