revJournal - Features

Dan Shafer on Revolution and OOP, Part II

In Part I of this article, we covered the basics of traditional OOP, and took a look at what it's all about and why it's favored by many professional programmers. This week, we'll consider OOP in the context of Revolution's object-based programming model...

OOP and Runtime Revolution

So what does all of this have to do with Runtime Revolution and Transcript? After all, we've already pointed out that Transcript is not an object-oriented program-ming language.

There are some strong parallels between Transcript and true OOP systems, though, and these parallels are neither accidental nor incidental. Although the parallels are not exact and don't hold up throughout the architecture of Transcript, they are interesting and important enough to merit our attention. My hope is that by seeing the aspects of design and programming that Transcript and more traditional OOP languages have in common, you will see how to take advantage of OOP concepts in designing stacks.

Objects in Transcript
There are 12 types of objects in Transcript: stacks, cards, buttons, fields, scrollbars, images, graphics, players, EPS (Encapsulated Postscript), audio clips, video clips, and groups. Like OOP objects, each of these can send and receive messages. Each type of object can be associated with a script that contains handlers, which correspond to methods (as we'll see in a moment). So the object and the program code that enables it to respond in a specific and predictable way to a message are packaged together, exactly like objects in an OOP environment.

Messages in Transcript
The parallel between OOP systems and Transcript continues when we examine the subject of messages. Transcript uses the same term to describe the communications that take place between objects. Transcript includes system messages that are sent as a result of events triggered by stack users. Each type of message can be addressed to one or more of the types of objects encompassed by Runtime Revolution.

When an event takes place, a system message is generated and sent to the object of which the event is the target. That object reacts as called for in the handlers contained in its script. The parallel with OOP is quite strong.

It is important to differentiate system messages, which are sent in response to user actions, from built-in commands and functions in Transcript. The latter are always handled directly by Revolution. In fact, you cannot intercept these built-in messages or change their behavior in any way. For example, the built-in command add that you use to add numbers is always handled the same way and only by Transcript. You cannot put a handler or function called add in your application and expect to treat the add operation differently.

Methods in Transcript
As we have pointed out, each type of object in the Runtime Revolution hierarchy can have a script associated with it. In each script there can be one or more handlers. These handlers correspond closely to OOP methods. A handler is associated with each type of message the object can receive.

There are two types of handlers in Transcript scripts: function handlers and event handlers. The latter derive their name from the fact that they are typically triggered by an event, as described in the preceding section.

All Runtime Revolution objects also have properties. Proper-ties are an important concept; they are discussed in depth in Chapter 18. Some properties bear a close resemblance to methods as well. For example, a button can have a property of being automatically highlighted when it is pressed. This is a character trait, or behavior, of the object, and so it corresponds at least roughly to a method. Revolution objects come with a set of built-in properties and you can add custom properties as needed to add characteristics to those objects.

Classes in Transcript
There is no strong analog in Transcript to OOP's concept of classes. The hi-erarchical form of inheritance (see the next section) used in Transcript is not precisely parallel to that of object-oriented programming, due in part to the lack of classes for objects. For example, there is no class called a button class to which all buttons belong and which has individual instances of buttons. Although there is some commonality of behavior among buttons ? they all, for example, cause something to happen when they are pressed ? there is really no classification scheme resembling OOP classes.

The concept of groups in Transcript bears some semblance of connection to the notion of an object in OOP, when groups are set up in such a way that they appear on multiple cards and both appear and behave identically on all of those cards. Creating a new card which contains one or more groups will, under the proper circumstances, place those groups on the newly created cards. The group object is not replicated, but rather exists in such a way that its script is executed regardless of the card on which it appears.

But groups are not, strictly speaking, classes. They simply exhibit some of the characteristics of classes in an OOP environment.

Inheritance in Transcript
There is no true inheritance in Transcript. Messages pass through a definite hierarchy (see Figure 2-4), and this hierarchy has some of the characteristics of OOP inheritance structures, but the analogy is less complete when it comes to inheritance than on any other point.

The hierarchy in Figure 2-4 extends up from the specific object where the action takes place that triggers the event, to the card, group(s), and stack, then to the Home stack, and finally to Runtime Revolution itself.

A mouseUp message that originates with the press of the mouse on a button gets passed up the hierarchy until one of two things happens: A handler named mouseUp is encountered and executed or the top of the hierarchy is reached with no handler having intercepted and acted on the message. This behavior is quite similar to the message-processing approach of OOP systems.

But the opposite is not true. In other words, just because a particular button on a card has the ability to respond to a specific type of message does not mean that all other buttons have the same capability. The same can be said of groups, cards, and stacks. If you create a new card, it may has the same group as the currently visible card depending on a specific property of the group. If the group has a handler for a particular system message in its script, the new card also has that same handler.

But this is not inheritance, because the new card is not a descendant of the original; both are on the same level of the hierarchy.

You can also modify the inheritance path dynamically in your scripts. You can place stacks and the scripts associated with specific objects in the current and other stacks into the message hierarchy between your stack and the Home stack. This makes it possible for you to redefine at least a significant part of the hierarchy and to create libraries of scripts that can be shared among other stacks only when they are needed. This type of reuse, which strongly resembles inheritance in OOP, can be a major design win when you build applications using Runtime Revolution.

Runtime Revolution
Home
Up to 10 other stacks
Stack
Background
Card
Button
or
Field

Figure 2-4. Transcript hierarchy of inheritance

How OOP thinking helps in stack design
You can see why we said at the outset of this discussion that Transcript is not a true OOP language, but shares enough with that approach to software design to merit consider-ation of the parallels.

We mentioned that code reusability is a major advantage of OOP systems. Because of the absence of true inheritance, that advantage does not accrue to Transcript. Thanks to cut-and-paste editing power, you can easily copy scripts and handlers from one object to another object of the same type (or even a different type). But this manual process, no matter how facile, hardly qualifies as inheritance of behavior from object to descendant object.

On the other hand, the isolated nature of a handler and its ease of modification mean that maintaining scripts is much easier than modifying and managing traditional procedural programs. If the handler works in response to the message it handles in one card or button, it will work correctly in another place. Similarly, if a script has more than one handler, even if they interact, the functionality is isolated to a sufficient degree that software maintenance is quite straightforward.

Finally, and perhaps most significantly to Transcript programmers, the language does a remarkably good job of emulating the world of which it is a model: that of a computer application. It makes working with the complex world of objects much simpler, more readable, and more enjoyable.

Partly because of its strong object influence and partly because of the nature of the computer world that lends itself well to such object emulation, Transcript removes many of the barriers between programmers and elegant, usable, GUI-based applications.


Dan Shafer is the Revolution guru behind the Revolution Pros website, and the author of the 3-volume official third-party Revolution book, Revolution: Software at the Speed of Thought.