This is an introduction to the concept of inheritance and object ancestry.
Software objects are described by their CLASS. The word "class" comes from biology, a discipline which makes fundamental use of a hierarchical system of organisation. This hierarchy can also be seen as a kind of evolutionary diagram.
Just for the sake of it, here is where we fit in:
kingdom: animal
phylum: chordata
class: mammalia
order: primate
family: pongidae
subfamily: hominidae
genus: homo
species: sapiens
...and of course, there is no need for any of us to remember all this because we all operate at the same level of the hierarchy: we all have more or less the same set of characteristics, we are all human beings. (Apologies to any smart creatures of other species who may be reading this).
It would be possible (and perhaps appropriate) to continue the diagram to include race, nationality, culture, tastes and so on, but that is where biology ends and anthropology takes over.
It is usually possible to get to know the interface of any other object, but it is easier to "interface with" another object who has many things in common with yourself, because you know yourself best of all.
When we start to keep pets, we have to learn their interface, and they can often be trained to learn ours, but we can never expect the same kind of relationship with a clever dog or a talking parrot as we can from an an object of type homo sapiens. Some people prefer pets to humans precisely because the interface is less complicated.
Each level of an object hierarchy describes a specialisation of the previous ones. An ape is always an animal somewhere along the line. Classes which are extended and specialised by other classes are known as ANCESTORS. Some ancestors are completely abstract - they must be further specialised if they are to be "useful", for example "mammal". There is no such species as a "mammal", but there are many creatures which are mammals. All classes are abstract. They only make sense when there are actual instances created from them.
Milk glands are not a unique characteristic of human beings, they are common property of all mammals. Ancestors tend to deal with things which the specialised object can not. Humans have no unique ability to suckle their young, we do it just like any other mammal.
When a message arrives in an object which is not understood, it is passed down the line of ancestors until there is a procedure to deal with it. One of the most interesting biological examples is the way we deal with fear.
When we are afraid, it is usually because we don't know how to deal with whatever (message or input) is frightening us. We pass the message back to our ancestral program which responds with instructions to various glands. Adrenalin levels rise and a set of "fight or flight" responses take over, about which we have no control.
A sprite object in Director understands very few messages from the outside, but has a set of properties which can be modified. By modifying the loc (location) property, the sprite draws itself in a different position at the next screen update. By modifying the member property, the sprite uses different media to draw itself on the screen. In Lingo, you can set a property of a sprite in the following way.
set the <property> of sprite s to <newvalue>
for example
set the loc of sprite 1 to point(320,240)
set the member of sprite 1 to member "myBitmap"
...but it is usually considered bad practice to set properties of an object from the outside. Imagine if someone dyed your hair while you were sleeping, or decided to give you a tattoo without asking you.
When you attach a scripted behavior to a sprite in Director, you are inserting an ancestor in the level above the sprite. This means that new properties can be added to the sprite. It can also be configured to respond to new messages.
A behavior / score script is an abstract / ancestor class which must be attached to (extended by) a sprite to be "useful".
A score script refers to the sprite channel where it is attached as...
the spritenum of me
Here is a "useful" example.
--Score script to change member easily--
property mySprite
on beginsprite me
set mysprite to the spritenum of me
end
on changeMem me, newmem
set the member of sprite mysprite to member newmem
end
After you attach this script to a sprite, you can run your movie and send the sprite a message, such as
sendsprite 1,#changemem, "flowers"
...and if you have a bitmap called "flowers", sprite 1 will use that bitmap instead of whatever it was using before to draw itself. The sprite object does not understand the message #changemem, so it passes the message to its ancestor, an object or instance of the class described in the script.
The me keyword is a way for the object to refer to itself. There can be hundreds of objects of the same class, each one needs to be able to refer to itself. Just as in English, objects refer to themselves as me, even if they might be known as
getat(the scriptinstancelist of sprite 1,1)
...from one level of a director movie and...
PicChangerObj
...from somewhere else. The phenomenon of objects having multiple names is quite natural:
The tall English guy with the ponytail
Our Director teacher
Brennan
darling
me
him over there
...can all refer to the same object. Notice that each name is suitable in a different context, and some names even specify a context.
Ancestors can have ancestors and a chain of inheritance can be built up which goes back for many levels. However, to create an ancestor for a score script, you are required to make a special kind of abstract class known in Director as a Parent Script. You then store a reference to an object of this class in a property called ancestor.