A dot.sytax lesson on objects

Date: Wed Dec 22 08:48:03 MST 1999
From: Steven Sacks <stevensx@bellsouth.net>
Subject: A dot.sytax lesson on objects

It's all about objects.

Once you start thinking about everything as objects you're on your way.

Graphics are objects.
Text members are objects.
Sprites are objects.
Behaviors are objects.
Sounds are objects.
Videos are objects.
Scripts are objects.
Director movies are objects.
The Stage is an object.
Frames are objects.
Lists are objects.

Everything is an object of some sort. Anything that is tangible in the Director environment is an object.

These objects have characteristics. In Director, these characteristics are sometimes called properties.

A graphic in the cast has characteristics. It has a height, a width, a forecolor and a backcolor. It has a rect, it has a registration point, it has a bit depth, it has a type. These are just a few of a graphic member's properties.

In regular syntax you put the property first and the object last:

the width of member "graphic"
the regpoint of member "graphic"
the rect of member "graphic"
the type of member "graphic"

With dot syntax, you put the object first and the property last and separate them by a dot:

member("graphic").width
member("graphic").regpoint
member("graphic").rect
member("graphic").type

This can be applied to any object.

The way dot syntax works with most objects is like this:

objectType(name of object).property

The objectType is where we put the type of object we are going to use. If our objectType is a sprite then we put sprite where object is.

sprite(name of object).property

The 'name of object' is a specific object of the objectType you are looking for. It can be a string or a number depending on what type of object it is. In this case it is a sprite, so we use a number as its identifier.

sprite(10).property

What is left is the property. Sprites have many properties.

the locH of sprite 10     >>   sprite(10).locH
the width of sprite 10    >>   sprite(10).width
the visible of sprite 10  >>   sprite(10).visible

Now then. It is possible for a property of an object to be another object. As we already know, objects have properties. So if the property of objectA is objectB, you need to remember that object_B also has its own properties. Confused? Stay with me.

Using a real example I'll explain.

objectA is our sprite. For this example we'll use sprite channel 10. objectB is a member in the cast. For this example we'll use a bitmap named "graphic"

One of the properties of a sprite is its member.

sprite(10).member

All that member property is, is a pointer to an object of another type. A cast member object, with its own set of properties.

Keeping with our example I'll continue.

In sprite channel 10, we have a cast member named "graphic". So

put sprite(10).member
-- (member 1 of castLib 1)

WAIT? What happened? I thought the cast member in sprite channel 10 was called "graphic". What's all that?

Well, remember that the cast member is also an object. And it is actually contained in another object, the cast. Yes, the cast is also an object. So when we ask a sprite what member it has in it, it asks the cast. In our example, the cast told it which slot it was in and in which cast it was in as well. But what if we want more detail?

Well, remember that members in the cast have their own sets of properties. We can get those properties the same way we do sprites.

put (member 1 of castLib 1).name
-- "graphic"
put (member 1 of castLib 1).regpoint
-- point(0,0)

We don't need to keep track of all that though, because Director does it for us. So when we say

sprite(10).member

It refers to the (member 1 of castLib 1) object.

Now that you see how it does that, you will understand this.

put sprite(10).member.name
-- "graphic"

What happened here is that the sprite object 10 has a member and that member has a property called name. You don't have to write it all out because you have already pointed to the exact member in the cast.

This can go as deep as it needs to.

objectType(name of object).property.propertyOfproperty. etc, etc.

A real life way of thinking about it is as such.

Organisms are classified into a hierarchical scheme. Think of these as director objects. In dot syntax it would look like this.

Kingdom.Phylum.Class.Order.Family.Genus.species

Species is a property of genus, genus is a property of family, etc. There are many species in genus and many genus in family. These are all properties.

A smaller picture is, say, your family.

family.father.name = "John"
family.mother.name = "Jane"
family.father.age = 40
family.father.eye.color = "Brown"
family.father.hand.left.finger.index

you see how it goes?

Once you think of objects in that way, things start falling into place, especially with dot syntax.

With objects and behaviors that use me, me is the object type.

me.myProp
me.myOtherProp

If you wanted to check the locs of 5 sprites in your score in one frame, you don't have to type

repeat with a = 1 to 5
  put sprite(a).loc
end repeat

What if the sprites are in channels 3,6,14,35, and 48?

How can you tell?

Well, if you make ONE behvaior OBJECT and put it on each sprite, you can.

--------
on giveLoc me
  put me.spriteNum & ": " & sprite(me.spriteNum).loc
end
--------

That ONE script is called a parent. Each of those sprites you drop is on are children. They each take on the me property as their own. Makes sense, right?

If I ask 5 people their name, they are all people right? They each have a name, but they are all people and therefore respond the same to the question.

giveMeYourName person

"My name is Bob"

sendAllSprites(#giveLoc)
-- 3: point(145,232)
-- 6: point(11,133)
etc.

They all respond to the message because each of them knows who they are.

I hope this opens your eyes somewhat to object oriented programming and dot syntax programming which is just an extension of that, and helps you to understand WHY it works as much as HOW it works.

For more info on OOP, I highly recommend reading Lingo Sorcery by Peter Small. For more info on dot syntax, check out the other two dot syntax articles written by Bruce Epstein and Zac Belado.

Gotta go,
Steven Sacks