The Object

personA = new Object();

There it is, personA is an Object. Lets just refresh ourselves on what you can do with an object. You can add properties to an object, like the following:

personA.name = "Ann";
personA.age  = 31;

Which means

- personA has a name, the name is "Ann"
- personA has an age, the age is 31

Simple enough. Here is another way to write the same thing:

personA= { name:"Ann", age:31 }

The curly braces { } are just a quick and handy way of making an object. Here is another object:

personB = new Object();
personB.name  = "Bob";
personB.age   = 25;
personB.hobby = "drinking";

Which again, is the same as saying:

personB = { name:"Bob", age:25, hobby:"drinking" }

Actionscript generally ignores whitespace. So to create the whole personA object you could have said: personA = { name : "Bob", site : "bob.com", favs : { site1 : "flash.com", site2 : "flesh.com" } } This is sometimes useful, but the giant show-stopper drawback it has is that it doesn't always allow comments. It's still probably worth memorizing the syntax for creating quick objects though: o = { x:x, y:y, z:{a:a, b:b} } Note the curlys, commas, colons, and the lack of semi colon at the end.

That was easy,. So now you have two objects: personA and personB. They each have the two properties name and age. personB has one extra property called hobby. Reread the example if you are not clear on this, because the very next sentence will be a very important one.

There is also a third object, somewhere, that has two properties - personA, and personB. This gives us the first glimpse of OO programming at work. Everything is inside an object.

If your eyes are starting to glaze over, wait... we'll back up, and bring in a new metaphor. Imagine someone is moving. This entails moving their stuff. There are two approaches here. One is to back up a vehicle to the front door, preferably one with a removable sun roof, and then empty out all their drawers, boxes and shelves into the vehicle. Clear a space for the driver, and off you go. This is the quickest and easiest way to move, and it works out better than you would think. However, the 'normal' way to move is by putting everything into boxes, and labeling all the boxes (perhaps somewhat cryptically) according to their contents. This involves thousands of decisions and prioritizations per hour. It's a great test of a marriage if you are ever looking for one.

Bob and Ann are moving. Lets help them by putting their stuff into boxes. Objects are like boxes, luckily, so this will not hurt our backs. It is a little known fact, but Americans are the most 'moving' people in the world (OK, after Tibetan nomads). Three out of five Americans move every five years. That comes to millions and millions of moves. Further research has revealed that in each and everyone of those moves, there has been a box labeled, "important stuff". As a nod to the tremendous value American people put on "important stuff", we'll start with that box.

importantStuff = new Object( );
importantStuff.money       = 500;
importantStuff.papers      = 96;
importantStuff.annPassport = "er246vjl";
importantStuff.bobPassport = "kl554mkt";

Can you see that we have added a few items to the box? So far so good. Well, maybe anyway. What if we put in something that is already in a box - for example a jewelry box?

importantStuff.jewelryBox = 1;

That seems right, but when Ann needs to find her necklace, will she be able to? We have put a list of the contents on each box, but her necklace will not be on the list. What we really should do is make a list of what is in the jewelry box, something like:

importantStuff.jewelryBox = new Object( );
importantStuff.jewelryBox.necklace1 = "Pearl";   // fake
importantStuff.jewelryBox.necklace2 = "Diamond"; // fake

Now the jewelry box has a list of what is inside it too (we keep our comments to ourselves of course). It isn't a perfect solution for her, because the list is on the jewelry box, inside the closed box. She still needs to open everything to find her necklace. Lucky for us however, this is exactly how objects behave in Actionscript, so we'll just leave the boxes as they are. Hope she doesn't mind.

There we go, we have put an object in an object - a box in a box. It is not a stretch now to see it going the other way too. Say they use two vehicles to move, a car and a truck. Some boxes go into one, some into the other. "Important stuff" ends up in the car, so the necklace can be found at car.importantStuff.jewelryBox.necklace1. This is much like what happened when we created personA and personB. We created them somewhere, and somewhere is always inside an object when you create things in Actionscript. In Ann's and Bob's world, it is easy to see that, eventually, the ultimate container will be Earth, Universe, Om. In Actionscript, OM exists too, taking the form of 'the object they call Object'.

So, these objects sitting in objects seem simple enough, but in order to really understand what is going on with them, we are going to have to dig quite a bit deeper. With this deeper understanding will come great power. Embrace it, feel it surging through your veins. Trust your feelings, Luke. I am your father. More on objects coming up...

The Object - Part II

Let's back up and try putting an object inside personA, just to see how that works.

personA.favs = new Object( );

Check your pulse - when it drops back down to a reasonable level, continue. We have just added a new property to personA, and it happens to be an object rather than text. We can add properties to this new object, favs, by just saying:

personA.favs.site1 = "flash.com";
personA.favs.site2 = "google.com";

This again was the same as saying:

personA.favs = { site1:"flash.com", site2:"google.com" }

So now you can say

personA has a property called favs, that has a property called site1, whose value is "flash.com".
personA has a property called favs, that has a property called site2, whose value is "google.com".

So now that you understand how to put an object in an object. You know everything there is to know about object oriented programming. Ha ha, just kidding, but not by as much as you might think. What is important to understand is what an object in an object implies. You probably know all this, having often put movieclips inside movieclips, but it's always good to summarize.

OBJECT LIFETIMES

The first, most obvious implication is that the inner (child) object is somewhat tied to the outer (parent) one. This is called a parent/child relation, though in this case it is probably more accurate to think of it as a mother/baby-in-the-womb relation. If the mother gets hit by a bus, the baby shares her fate. If you delete the parent object, the child object is gone too. Of course the opposite is not true - if you delete the baby object, the parent is still there, just minus one baby object (insert heated political discussion here). Notice lastly that child objects can only have one parent, which might seem confusing. Babies can only have one mother, objects only one parent (think queen ant if there are lots of objects!). There are other types of parent/child relations which we will eventually discuss.

SCOPE

A second consequence of having nested objects is their 'scope'. Scope means something like 'context', in the sense of 'what can be seen/understood from different places/points of view'. Taking the baby metaphor again, the baby can 'see' inside its mother (with a flashlight), but it can not see what its mother sees. In Actionscript you can reference an object's scope automatically - the first place Actionscript will look for a property is the object's own scope.

The feature of boxes that we have been interested in is not the cardboard, it is their 'containerability' (nod to gwb). Containers can be filled with all sorts of things, including other containers. From within a container, you can see all the other objects inside it, but not the ones outside it. And although you may see other containers from within your 'scope', you will not be able to see inside them. Whew, this would be a good time for an example, it's not complicated at all. Let's make yet another personA object:

personA= 
{
  name : "Ann",
  favs :
  { 
    site1 : "flash.com",
    test1 : function(){ trace (this.site1) },
    test2 : function(){ trace (this.name ) }
  },
  test3: function(){ trace (this.name ) },
  test4: function(){ trace (this.site1) }
};

personA.favs.test1(); // flash.com
personA.favs.test2(); // null (child can't see parent)
personA.test3();      // Ann
personA.test4();      // null (parent can't see child)

In this example, the 'this' keyword means 'the container that called this function', which is conveniently the container we are trying to see inside. It isn't necessary to understand how that works at this point, but to describe what each 'test' property is returning in plain old English:

test1: The property called site1 
       in this container (personA.favs).
       // which has the value "flash.com"

test2: The property called name 
       in this container (personA.favs). 
       // there is no such property in personA.favs

test3: The property called name 
       in this container (personA).
       // which has the value "Ann"

test4: The property called site1 
       in this container (personA). 
       // there is no such property in personA

What happens if we change test4 to say:

test4: function(){return this.favs.site1;} // note the '.favs.'

Well, happily it now works. What does it return?

test4: The property called site1, 
       in the container called favs, 
       which is in this container.
       // ? Try find the value using the new test4 code...

NAMESPACE

This has pretty much been covered in the last example, but it is worth mentioning specifically. Everything has its place, and that place is given a name. You should be very happy about this, because it is a great way to organize your program. In fact it is how people naturally organize things in the real world. Think of your address. It's probably something like - name, house#, street, neighborhood, city, state, country. The postal system relies on this to find you. Programs used to be written as a bundle of 'names', but as they grew bigger (like to the size of small cities) this became impractical. A better system was needed to organize this complexity. One of the main benefits of object-oriented programming is that it organizes complexity. Everything has an 'address'. From this address you can only see certain things. There are no global variables (properties that can be seen from anywhere) in object-oriented languages for a good reason - you are using object-oriented techniques because you want to organize things. The postal system would be unable to function properly if people were allowed to just use a name for an address, and eventually so does a program.

Key object-oriented concept: It is very important to always be thinking where things should go in your program. How you will do a certain task is often much less important than where you will do it. Compare the importance of location and technique for a couple having sex in a fast food restaurant. It's that kind of thing...

Has-a Relations

OK, that was easy enough. You can create objects, objects have properties (which are often called members or attributes), and these properties have a name and value. As we have seen, these properties can also be other objects, which can also have properties, and this starts the whole ball rolling again. This type of relationship between objects is called a 'has a' relationship. You will probably find object-oriented terminology full of words that are too big, like 'polymorphism', and 'encapsulation', and then many words that seem too small, like 'this', 'has a', or 'is a'... Luckily these concepts are harder to name than understand.

A 'has a' relation is when one object 'has-a' nuther object inside it. For example a car 'has-a' gas tank. It 'has-a' steering wheel. It 'has-an' engine. ('has-an' means the same thing as 'has-a'. Whew!). This is obvious, but it can get tricky when compared with the other main type of relation between objects, 'is-a' (a car is-a vehicle, a car is-a machine). These two concepts are very central to object-oriented programming.

But, we are ahead of ourselves. Feel free to play around with the exercises below, then we'll move on to classes - templates for creating objects.

== Exercise ==================
Here are some sample objects that you can practice sorting, some are easy, some are hard, some have no best answer. (just drag things around to sort them)
<<link to swf>>
===============================

Introduction < < Home > > Classes