What is Ptolemy?

Ptolemy is a programming language whose goals are to improve a software engineer's ability to separate conceptual concerns. In particular, Ptolemy's features are useful towards modularization of crosscutting concerns.

Isn't Ptolemy just an OO language with native event handling?

At a first glance this is one of the distinctions between Ptolemy and object-oriented languages such as Java. Programming languages such as C# eliminate a bit more of these distinctions because they support basic event handling as a language feature.

However, Ptolemy also provides event types as a mechanism to:

• Refer to a number of places in program where an event is triggered using the name of the event type. This is done without having to name the classes that trigger the event. In aspect-oriented terminology this is called quantification. This distinction is important for implementing crosscutting requirements (see below for more).
• Provide overriding behavior. This distinction is important for implementing overriding features like exception handling, fault tolerance, etc.
• Achieve 2-way decoupling between subjects and observers (whereas traditional event handling mechanisms only decouple subjects from observers). This distinction is important for improving reuse of modules in a software system.

What is implicit invocation (II) design style?

We have prepared a brief background on implicit-invocation (II) design style and its limitations see here.

What is Aspect-oriented Programming (AOP)?

For a brief background on aspect-oriented programming see here.

Is the primary benefit to AOP that it automates adding the same lines of code to every method?

No, we elaborate below.

With traditional object-oriented techniques, when we implement some requirements (e.g. exception handling, synchronization, resource sharing and other resource management protocols, logging, etc) such implementation is typically scattered everywhere in the software and tangled with implementation of other requirements. Such requirements are called crosscutting requirements. As a result, when maintenance requests arise in these type of requirements developers have to study a large number of modules in the software system to identify changes that are required to address maintenance request.

Objective of aspect-oriented software development (AOSD) is to provide programming language mechanisms that enable software developers to implement these type of requirements (e.g. exception handling) in separate modules.

Why was the Ptolemy language designed?

The Ptolemy language was designed to combine best ideas from implicit invocation (II) design style and aspect-oriented (AO) languages in the style of AspectJ and to not have the limitations of these styles. Briefly, Ptolemy was designed to solve the following problems with AO and II paradigms:

• AO: quantification failure, fragile pointcuts, limited context information
• II: coupling of observers, no replacement of event code, no quantification

For a more detailed motivation of the language design, please see our web-page on this topic here.

What are the design goals of the Ptolemy language?

Ptolemy has the following main design goals:

• Preserve encapsulation of object-oriented code, while enabling modularization of crosscutting concerns,
• enable well-defined interfaces between object-oriented code and crosscutting code, and
• enable separate type-checking, separate compilation, and modular reasoning of both object-oriented and crosscutting code.

All these goals are important for scalability of software development processes but harder to achieve in current AO languages in the style of AspectJ.

Do you have a compiler?

Yes. The Ptolemy compiler offers support for compiling and running programs from command-line as well as from within Ant. To get started with setting up an environment for running Ptolemy programs please see our page on installing and running the compiler.

Once you have downloaded and installed the compiler, you could look at the examples included in the distribution. Or alternatively, you could also consult our web-pages on getting started with Ptolemy.

Can I download the source code for the Ptolemy compiler and modify it?

Yes. The Ptolemy compiler for Java programs is an open source project on sourceforge.net.

Isn't an event type just a method signature in disguise?

No. A method signature is an abstraction for the body of a single method. On the other hand, an event type p is a two-way abstraction -- an interface between subjects that signal p and handlers that run when p is signaled. For subjects that announce event p, it is an abstraction for a chain of 0 or more handlers that may be fired when the event p is announced. For event handlers of p, it is an abstraction over 0 or more subjects that may signal the event p. Furthermore, this abstraction allows programmers to write more expressive contracts.

Doesn't explicit event announcement defeats the primary strength of AspectJ where events occur implicitly?

Yes, and it is intentional. An announce statement of the form announce p(...) { ... } explicitly signals an event p. It does NOT, however, explicitly names event handlers of p.

The advantages of explicitly signaling events are in terms of understanding and maintaining programs. Following advantages accrue from explicit event announcement in Ptolemy.

• Programmers can be sure that program locations that do NOT have announce statements are NOT going to be affected by event handlers. Therefore, the runtime behavior at those program locations will match the static source code. This simplifies understanding and reasoning about programs.
• Source code changes in subjects do not cause handlers to break. This problem, known as pointcut fragility, is avoided entirely.
• Arbitrary program points can be exposed by explicitly signaling events. This avoids another problem known as quantification failure.
• Since event type declarations have lightweight translucid contracts that give insight into the potential behavior of handlers, programmers have an improved understanding of the program's runtime behavior.

Page last modified on $Date: 2011/08/04 00:46:02 $