[14.5] So what about that "trickier bit" you mentioned up there in 14.3? You know, when, where and how to use parents and children?

Traditionally, the principal benefits of programming with objects are encapsulation, modularity and reusability. In theory objects also help you to relate the workings of your program to the workings of the corresponding entities in the real world.

Encapsulation is one of the most significant benefits of object-oriented programming in Lingo. It's really just a fancy way of saying that you can separate out all the stuff associated with a particular entity so that it doesn't get confused with everything else that's going on. Ideally, objects should allow whole slabs of your code to exist as almost wholly independent mini-programs, communicating with everything else through a small, easily understood interface. All the complexity involved should be hidden away out of sight to let you concentrate on the bigger picture.

By the same token, a carefully encapsulated object will discourage you from just wantonly messing with all the data and processes involved. By handling everything through the defined interface methods instead you can be relatively sure that everything will remain under control. The parent script should be able to be written and tested independently and then just plugged into your program as an opaque, dependable machine.

Many objects will be sufficiently general that you can just extract them wholesale from one movie and stitch them into another with only minor changes, and because you know it worked in the previous movie you can be fairly sure it will when used the same way in the new one, so once you start to build up a library of useful parent scripts, you'll find you have to invent less and less from scratch.

All of which is perfectly fine, but where do you start?

As mentioned earlier, the traditional way of devising uses for objects is to relate them to what actually happens in the real (or perhaps imaginary) world your movie represents. That is, you structure your program as a collection of objects that correspond to the things you are modelling.

For example, if you were constructing a movie about Renaissance artists, it might make sense to create a set of "artist" objects, each of which would store everything associated with a particular artist. It might have properties such as dates of birth and death, country of origin, school, patron, a list of famous works and so on. The artist object would encapsulate everything you needed to deal with about any particular within a single structure.

Similarly, many games break down easily into a bunch of entities that all have to be managed quite separately. Frogger, PacMan or Donkey Kong would all be good candidates, but let's consider Galaxians. All of the alien invaders in any one wave are pretty much the same, but all of them have distinct attributes. The player's ship is quite separate from all of them, while the missiles s/he shoots are all the same as each other but each one operates as an independent object. So, for example, one could choose to decompose the whole game into a collection of objects birthed from only three parent scripts: aliens, player ships and missiles.

In practice it would inevitably be more complex than that, but this does serve to illustrate two key points about objects. First of all, they are useful for separating things out from one another and treating them as self-contained units. Secondly, they are particularly relevant when dealing with a large number of basically similar things which differ only in a few specific properties (such as position and velocity). If your Lingo code has to deal with a whole bunch of things that are all very much alike, they may well be suited for objectification.

As well as the general theoretical advantages of objects, there are a number of Director-specific features that can make them very useful for particular tasks.

For one thing, objects can be passed around from movie to movie as ordinary global variables and retain all the handlers written into them. Since all Lingo code is otherwise forgotten when you go to a new movie, this can be a good way of sharing code between a bunch of separate movie files, even to the extent of allowing you to install various activities that the current movie may not (and doesn't *need* to) know about. This can be helpful when debugging, for example.

The other really useful Director feature that uses objects is the actorlist. Although this isn't comprehensively documented, it provides a simple method for handling periodic tasks without having to specifically code them into individual frames. All objects placed into the actorList using code like this:

    add the actorList, me

    -- simple stepFrame-driven animation that cycles through all the
    -- casts from myStartCast to myEndCast in sequence in channel
    -- mySprite

    -- mySprite, myStartCast and myEndCast are all properties
    -- and have to be set sometime before the object is put into
    -- the actorList (perhaps in the birth handler)

    on stepFrame me
      if the castNum of sprite mySprite = myEndCast then
        set the castNum of sprite mySprite = myStartCast
      else
        set the castNum of sprite mySprite =
          (the castNum of sprite mySprite) + 1
      end if
    end stepFrame

In conclusion, then, the cases when you might benefit most from using parent scripts and child objects are when one or more of the following apply:

• you need to deal with lots of very similar entities that all have slightly different properties or values but otherwise all behave in basically the same way
• you want to isolate specific chunks of your program that are mostly self-contained, or group together a bunch of handlers that all need to deal with the same, self-contained collection of data
• you need to share a bunch of handlers among several movies
• you want to take advantage of the periodic or asynchronous task capacities of the actorlist