Showing papers by "Gregor Kiczales published in 1996"

Aspect-oriented programming

Abstract: The performance of relational database applications often suffers. The reason is that query optimizers require accurate statistics about data in the database in order to provide optimal query execution plans. Unfortunately, the computation of these statistics must be initiated explicitly (e.g., within application code), and computing statistics takes some time. Moreover, it is not easy to decide when to update statistics of what tables in an application. A well-engineered solution requires adding source code usually in many places of an application. The issue of updating the statistics for database optimization is a crosscutting concern. Thus we propose to use aspect-orientation to automate the calculation. We show how nicely the update functionality can be modularized in an aspect and how easy it is to specify the exact places and the time when statistics updates should be performed to speed up complex queries. Due to the automatic nature, computation takes place on time for complex queries, only when necessary, and only for stale tables. The implementation language for the automated aspect-oriented statistics update concern is AspectJ, a well known and mature aspect-oriented programming language. The approach can however be implemented in any other aspect-oriented language. Unlike in traditional object-oriented pattern solutions, e.g. using the interceptor pattern, we do not have to modify existing code.

Beyond the black box: open implementation

Abstract: Encapsulation, informally known as black-box abstraction, is a widely known and accepted principle. It is a basic tenet of software design, underlying approaches to portability and reuse. However, many practitioners find themselves violating it in order to achieve performance requirements in a practical manner. The gap between theory and practice must be filled. Open implementation is a controversial new approach that claims to do just that. The paper provides some ideas to spark further debate on black-box abstraction.

High-level loop fusion

Abstract: A processor is provided with a software program specifying an overall computation that includes operations. Each operation implies a set of subcomputations, without explicitly specifying a control structure for carrying out the subcomputations according to a particular sequencing. The operations include a first and a second operation, and the provided software program further specifies how the first and second operations are combined in the overall computation. For example, the first and second operations can each imply, respectively, a first and a second computational loop, the first loop including the subcomputations of the first operation, the second loop including the subcomputations of the second operation. A description of possible sequencings of subcomputations of the first and second operations is provided, to be used in implementing the specified combination of the first and second operations, the description including a set of constraints on the sequencing of subcomputations of the first and second operations. A software program is automatically generated that includes a combined operation implementing the specified combination of the first and second operations. The combined operation has a control structure for carrying out the subcomputations of the first and second operations in accordance with the constraints. This control structure can be, for example, a computational loop. If the first and second operations imply, respectively, first and second computational loops, the control structure of the combined operation can be, for example, a computational loop including a fusion of the first and second loops.

Avoiding Confusion in Metacircularity: The Meta-Helix

Abstract: A system with a metaobject protocol (MOP) allows programmers to extend it and then use the extended system as naturally as the original non-extended one. Such metaobject protocols often use a metacircular architecture to make the extensions easier to write. Unfortunately, this use of metacircularity can lead to problems stemming from a conflation of the extended and non-extended functionalities. We present a new architecture, called the meta-helix, that preserves the advantages of metacircularity but also addresses the problems with conflation.

What can programming languages contribute to software engineering, and vice versa? (panel)

Abstract: Many would argue that programming languages are essentially irrelvant to software engineers: the real problems are not in the way we code our implementations but the processes, environments, and methods that we use to carry out system development throughout the lifecycle. On the other hand, a number of programming languages and systems have recently been developed with specific problems of software engineering in mind, by including advanced modularization capabilities, support for dynamic system composition, and the ability to create new applications from widely distributed componentry. This panel examines the extent to which such new language capabilities are likely to affect the practice of software engineering.