Ptolemy: A Language with Quantified, Typed Events

Motivation

The objective of both implicit invocation (II) and aspect-oriented (AO) languages is to improve a software engineer's ability to separate conceptual concerns. The problem that they address is that all dimensions of design decisions, or concerns, are not amenable to modularization by a single dimension of decomposition. Instead, some concerns cut across the dominant dimension of decomposition. These approaches aim to improve the separation of these types of concerns thereby enhancing modularity.

The key idea in II languages is that some interfaces declare events, allowing one set of modules to contain code that dynamically and explictly announces events, while a second set of modules dynamically registers methods, called handlers, to receive calls (the implicit invocations) when events are announced. The two sets of modules are independent of each other and need only share the event interface declarations.

In AO languages such as AspectJ events (called ``join points'') are pre-defined by the language as certain kinds of standard actions (such as method calls) in a program's execution. AO events are all implicitly announced. Pointcut descriptions (PCDs) are used to declaratively register handlers (called "advice") with sets of events. Using PCDs to register a handler with an entire set of events, called quantification, is a key idea in AO languages that has no counterpart in II languages. A language's set of PCDs and its set of events form its event model (in AO terms this is a "join point model").

II Languages have three limitations. First, they require complex event declaration, announcement, and registration code scattered across the system. Second, the ability to replace the code for an event (what AO calls "around advice"), is not available, without unnecessarily complex emulation code (to simulate closures in languages such as Java and C#). Third, quantification is not easy, since no abstraction like PCDs is available. Instead, a non-trivial strategy, such as a subscription registry, is needed.

AO languages also have limitations, primarily because most current event models use lexical PCDs. Such PCDs use patterns of names; for example, call(run*(..)) describes a set of call events in which the name of the called method starts with run. Lexical PCDs are fragile, exhibit quantification failures, and make it unnecessarily hard to uniformly access information from an event's context.

Figure 1: Overview of the coupling structure in Observer design pattern, aspect-oriented programming, and Ptolemy's quantified event types.

Ptolemy solves the problems with II and AO languages using quantified, typed events. Ptolemy's event types are named when they are declared, and these names can be used in quantification. An event type p also declares the types of information communicated between announcements of events of type p and handler methods.