Chapter 1 Overview

1.4 AM2 Philosophy

The ADL is a means of specifying an entire AM2 application, with particular efficiency in describing user interface templates and their associated functionality. It also provides easy access to and manipulation of the underlying system objects provided by the AM2 run-time environment.

The design team selected C++ as the AM2 implementation language both for its portability and relative efficiency. While C++ is an extremely rich and complex programming language, the ADL
requires only a small subset of that functionality. The language features supported by the ADL are
both necessary to its task and sufficient to accomplish it. That is, the ADL supports the minimal set of language constructs necessary to specify the general set of multimedia applications.

The ADL never allows a C++ usage to have a different meaning in the ADL than it would have in
C++. Nor does the ADL arbitrarily express C++ concepts using non-C++ usage without very strong reasons for all such variations. For instance, the ADL uses the keyword common to designate what in C++ would be a class static data member in order to reduce the ambiguity of the much overused static declaration. Any ADL concepts or mechanisms that C++ does not support are directly required by the ADL's particular multimedia mission. For example, the list compound data type is highly desirable to support the construction of messages at run-time and to facilitate communication with underlying databases.

It is worth acknowledging the two single most important differences between the ADL and C++.
First, the ADL does not associate pointers with specific data types as C++ does. And second, the ADL allows the entire contents of a message to be determined at run-time including the message selector and the number of arguments.

AthenaMuse was originally intended to offer transparent application portability across Windows, UNIX, and the Macintosh. Work on the Macintosh platform has been discontinued as of the summer of 1996, but the goal of application portability has been met on the other platforms. It is worth noting certain principles of AM2's approach to platform portability:

• Since application portability is a goal, the use of platform specific features is discouraged, but not forbidden. That is, AM2 should not deny the developer access to platform-specific features, but neither should it encourage their use.

• By default, an application running on a UNIX version of AM2 should obey the Motif look and feel, while a version running under Windows should obey the Windows user interface guidelines. The preliminary Macintosh version followed the same principles.

The later feature makes the former less bothersome. AthenaMuse classes attempt to embody semantic functionality rather than low-level feature sets. For instance, the AM2 approach to menus is platform independent. It is the registration of the menu with a particular application on a particular operating system that determines the visual style of the menu (e.g., pull-down or pop-up, tear-off, etc.).

Generated with Harlequin WebMaker