Aspect oriented programming

This task has been flagged for clarification. Code on this page in its current state may be flagged incorrect once this task has been clarified. See this page's Talk page for discussion.

Aspect oriented programming is a draft programming task. It is not yet considered ready to be promoted as a complete task, for reasons that should be found in its talk page.

The main goal of Aspect Oriented Programming (AOP) is to keep all the code relating to a single feature in one module of code.

There are a variety of ways to achieve this with object-oriented programming and functional programming, including inheritance, decorators and configuration trees.

In Aspect Oriented Programming existing code is extended with new behaviors invisibly, by means of stealthy instrumentation. There are some similarities between this concept and some debugging tools, such as Linux Kernel Probes. In fact, one obvious application for AOP is to add detailed tracing, with access to data, without touching the instrumented code. An aspect could be used to capture the calls to an entire API and log the arguments and return values.

The idea is that when the instrumented function is executes, either prior the execution of function, or at its point of return, or both, a block of code in instrumenting module is able to gain control. It can obtain access to the function arguments almost as if it were its own arguments, execute its own logic, and even decide whether or not the instrumented function will run at all, and with what argument values, and what it shall return.

Furthermore, there can be additional refinements, such as instrumenting calls to some function A, but only when it is directly called by function B. Or only when function B is somewhere in the activation chain, etc.

Also part of AOP is the idea of instrumenting data structures such as classes. An "aspect" is a hidden extension to some existing set of classes, which adds hidden new instance variables to the class. These variables are not accessible by the class itself, only by the instrumenting Aspect code. An object-oriented Aspect resembles a class, except that its instance variables are injected into another class (or classes!), and its methods are instrumenting hooks that capture control from the methods of other classes.

An Aspect Oriented Programming System provides the abstractions to make this happen: a way to write aspects which specify what classes and methods they instrument, and the code, data and activation rules for doing it.

AOP introduces some new terms. A "join point" is a place in the control flow where code is instrumented, like a function call or return. A "point cut" is a selection of join points according to some query, which are tied to a common instrumenting code. (A single instrumenting function can handle a large point cut of different join points.)

AOP allows for a "separation of concerns" because new features are introduced as aspects tied to the execution of existing code, but without touching any of it, thereby keeping code bases completely separate. For instance, a mutex locking discipline can be added to a class without touching any of its code. An aspect identifies the methods that need locking, introduces the mutex variable into every instance of every instrumented class, and gains control around the invocations of the targetted methods to manage the mutex. Without AOP, the concern for locking is spread everywhere. Mutex lock/unlock calls have to be written or at the very least, methods have to be declared as synchronized, and this is repeated in every class that requires locking.

Task

The task is to describe or show how, or to what extent, a given programming language implements, or is able to implement or simulate, Aspect Oriented Programming.

C

It can be difficult to modularise features in C, if the feature affects different parts of the program.

Using a define var

When a new feature introduces code scattered throughout the program, we can relate all the code together using a define and ifdefs.

<lang c>

1. define MY_NEW_FEATURE_ENABLED

...

1. ifdef MY_NEW_FEATURE_ENABLED

 my_new_feature();

1. endif

...

1. ifdef MY_NEW_FEATURE_ENABLED

 close_my_new_feature();

1. endif

</lang>

As well as allowing us to enable or disable the feature at compile time, this also provides a way to find all the relevant code easily, by searching for the variable name.

The same approach using a boolean instead of a define variable can be found in many languages, to allow a feature to be toggled on or off at runtime.

Using a macro

An alternative macro method can be used in C, which is shorter for one-liners.

<lang c> /* Enable logging: */ /* #define LOG(x) printf("%s\n",x); */ /* Disable logging: */

1. define LOG(x)

...

LOG(blah)

... </lang>

Using function pointers

In C a class-like object can be created using a table, or more commonly, a structure containing function pointers. This is often done in kernel programming for device drivers.

Here is a typical layout:

<lang c>struct object {

 struct object_operations *ops;
 int member;

};

struct object_operations {

 void (*frob_member)(struct object *obj, int how);

};</lang>

In this example, an object is constructed as an instance of struct object and the ops field is filled in with a pointer to an operations table of type struct object_operations. The object is usually dynamically allocated, but the operations table is often statically allocated, and the function pointers are statically initialized.

A call to the frob_member method, if coded by hand without the help of any macros or wrapper functions, would look like this:

<lang c>pobj->frob_member(pobj, 42);</lang>

This representation opens the door to various possibilities. To gain control over all of the calls to an object, all we have to do is replace its ops pointer with a pointer to another operations structure of the same type, but with different function pointers.

With some further refinements and hacks, we can create a way for our "aspect" can keep additional context for itself, but associated with the original object, including a pointer to the original operations which the instrumenting operations can call.

Of course, this is a far cry from being able to instrument multiple functions from different classes across an entire hirarchy, in a single place.

Common Lisp

A library was developed by Pascal Costanza called [AspectL].

However, the claims that "[i]t turned out that the pointcut functionality of AspectL does not make a lot of sense in Common Lisp, and the support for dynamically scoped generic functions has been replaced with much better mechanisms in [ContextL]."

F#

An Aspect-Oriented Framework for F#

J

In as much as I am unable to see the differences between functional programming and aspect oriented programming (they are just that stealthy, from my point of view), I'll have to say that J is as aspect oriented as the capabilities of the programmer.

Java

Java has an aspect oriented programming library called AspectJ. Aspects can create entry and exit intercepts on normal methods. In aspect language, features are called cross-cutting concerns.

JavaScript

Bemson's Flow library introduces an aspect-like framework for JavaScript.

Kotlin

The most popular framework for aspect oriented programming in Kotlin JVM is probably Spring AOP which is simpler and seems to have less issues than AspectJ, described in the Java entry.

However, one issue Spring AOP does have is that it expects all classes to be open to inheritance whereas in Kotlin the default is for classes to be closed to inheritance though this can be changed by use of the 'open' modifier. To deal with this, JetBrains provide an 'all open' compiler plug-in which makes all classes annotated with specific annotations (such as @Configuration or @Service) open without the need for the 'open' modifier.

Perl 6

All methods in Perl 6 are really just routines under the control of the meta-object protocol for purposes of dispatch, so there are several ways to subvert the system in order to deal with aspects. First, you could intercept the MOP calls, or you could install alternate metaclasses. More likely, since methods are really just routines in disguise, and since a routine can be wrapped (in place) in an outer routine via the .wrap method, you'd just wrap all the methods and other routines that share a cross-cutting concern.

Note that the optimizer is free to assume routines are immutable after CHECK time (the end of compilation), so while you can always wrap routines during compile time, you might need a "use soft" declaration or some such to enable wrapping at run time, that is, in order to keep considering the routine to be mutable. (Only code doing the Routine role is ever mutable in Perl 6—bare blocks and other lambdas are considered immutable from the start.) Note that keeping routines mutable is likely to pessimize spots where the optimizer might otherwise be able to inline the code.

Of course, you can also simply redefine Perl 6 on the fly to be any language you want in the current lexical scope, so you are really only limited by your imagination in how you wish to express these "aspects", whatever you might mean by that term…

Python

Python has special syntax for decorators acting on functions and methods, as well as metaclasses.

Tcl

Tcl's trace command enables much AOP-like functionality, with variable traces allowing interception of accesses to variables, and command traces allowing interception of executions of procedures, etc. In addition, TclOO (Tcl's object system) also supports filter methods, which wrap around invocations of methods of an object (or all methods of a class) as a generalisation of before, after and around advice. This works well when combined with a mixin, allowing interception to be applied on a per-instance basis if desired.

For example: <lang tcl>oo::class create InterceptAspect {

   filter <methodCalled>
   method <methodCalled> args {
       puts "[self] - called '[self target]' with '$args'"
       set result [next {*}$args]
       puts "[self] - result was '$result'"
       return $result
   }

}

oo::class create Example {

   method calculate {a b c} {
       return [expr {$a**3 + $b**2 + $c}]
   }

}

Example create xmpl puts ">>[xmpl calculate 2 3 5]<<" oo::objdefine xmpl mixin InterceptAspect puts ">>[xmpl calculate 2 3 5]<<"</lang>

Output:

>>22<<
::xmpl - called '::Example calculate' with '2 3 5'
::xmpl - result was '22'
>>22<<