Aspect oriented programming: Difference between revisions

=={{header|6502 Assembly}}==

The easiest way to do this is by putting every related function into the same file. One important thing to remember is that in 6502 (and most other assembly languages for that matter, unless linkers are involved), the order in which your code is placed implies its memory location. This is not the case in other languages, not even in [[C]].

SwapXY:

pha

NewLine: ;the above function will be stored in memory above this one.

lda #13

This is somewhat relevant because it lets you abuse fallthrough. If you have a special case of a particular function that you use often, you can easily make that special case its own function by having it load those specific parameters and then "falling through" into the function you're actually running. This helps to reduce call/return penalties while keeping your relevant pieces of code together. Unfortunately, you can only do this once per function, for obvious reasons.

LDA #10 ;linefeed

;the PrintChar function is literally below this line, both in a source code sense and a memory layout sense.

;input: A = the ascii code you wish to print to the screen.

;

=={{header|Ada}}==

Example parent package specification:

function Add2 (X : in Integer) return Integer;

Example parent package body:

function Add2 (X : in Integer) return Integer is

end Add2;

Example child package specification:

function Add2 (X : in Integer) return Integer;

Example child package specification:

package body parent.child is

end Add2;

The following program demonstrates calling both the Add2 function from the parent package and calling the Add2 function from the child package. The child package has visibility to the public portion of the parent package and can therefore call the parent's Add2 function directly.

with Ada.Text_IO; use Ada.Text_IO;

Result := parent.child.Add2 (Num);

Put_Line ("Result : " & Result'Image);

{{output}}

<pre>

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

#define MY_NEW_FEATURE_ENABLED

close_my_new_feature();

#endif

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.

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

/* Enable logging: */

/* #define LOG(x) printf("%s\n",x); */

...

===Using function pointers===

Here is a typical layout:

struct object_operations *ops;

int member;

struct object_operations {

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

In this example, an object is constructed as an instance of <code>struct object</code> and the <code>ops</code> field is filled in with a pointer to an operations table of type <code>struct object_operations</code>. 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 <code>frob_member</code> method, if coded by hand without the help of any macros or wrapper functions, would look like this:

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 <code>ops</code> pointer with a pointer to another operations structure of the same type, but with different function pointers.

┌─┐

│8│

Or, generally speaking, J provides us with the ability to wrap arbitrary statements with information gathering statements while allowing the original expression to proceed. (And, if we enable debugging, this information gathering can examine the surrounding context, gathering and reporting information on the calling environment, inspecting the local symbol table, the names of routines, the defining script(s), etc.)

=={{header|Julia}}==

Several of Julia's graphics frameworks use the idea of a backend for graphics, where the graphics module wraps and extends a lower level graphics framework. The use of one module to wrap another captures most of the ways in which aspect programming seems to be used. As an example, here we add logging to a module. Users of the Adder module can simply import the LogAspectAdder module instead of the Adder module to add logging to the functions of the Adder class.

exports add2

end

end

=={{header|Kotlin}}==

Actually, there is one way to instrument (specific) calls without modifying the existing code. Suppose you have somelib.e, containing:

<span style="color: #008080;">global</span> <span style="color: #008080;">procedure</span> <span style="color: #000000;">saysomething</span><span style="color: #0000FF;">()</span>

<span style="color: #7060A8;">puts</span><span style="color: #0000FF;">(</span><span style="color: #000000;">1</span><span style="color: #0000FF;">,</span><span style="color: #008000;">"something\n"</span><span style="color: #0000FF;">)</span>

<span style="color: #008080;">end</span> <span style="color: #008080;">procedure</span>

Then write wraplib.e as follows:

<span style="color: #008080;">without</span> <span style="color: #008080;">js</span>

<span style="color: #008080;">include</span> <span style="color: #000000;">somelib</span><span style="color: #0000FF;">.</span><span style="color: #000000;">e</span> <span style="color: #008080;">as</span> <span style="color: #000000;">somelib</span>

<span style="color: #7060A8;">puts</span><span style="color: #0000FF;">(</span><span style="color: #000000;">1</span><span style="color: #0000FF;">,</span><span style="color: #008000;">"thingwrap\n"</span><span style="color: #0000FF;">)</span>

<span style="color: #008080;">end</span> <span style="color: #008080;">procedure</span>

And replace all (existing) "include somelib.e" with "include wraplib.e". Hopefully there will be (and usually there is) only one.

Personally, while I might begrudgingly accept that sort of thing for the occasional quick 'n dirty, or a temporary debug aid, I am strongly opposed to it being permanent, and instead strongly believe '''code should do what it says it does''', no more and no less. For easy toggling, my own code tends to be littered with things like:

<span style="color: #008080;">global</span> <span style="color: #008080;">constant</span> <span style="color: #000000;">NEWFEATURE</span> <span style="color: #0000FF;">=</span> <span style="color: #004600;">true</span>

<span style="color: #0000FF;">...</span>

<span style="color: #008080;">if</span> <span style="color: #000000;">NEWFEATURE</span> <span style="color: #008080;">then</span> <span style="color: #0000FF;">...</span>

I also actually favour explicit shims, almost exactly what the task is asking for a way to avoid doing, such as

<span style="color: #008080;">function</span> <span style="color: #000000;">my_length</span><span style="color: #0000FF;">(</span><span style="color: #004080;">sequence</span> <span style="color: #000000;">s</span><span style="color: #0000FF;">)</span> <span style="color: #008080;">return</span> <span style="color: #7060A8;">length</span><span style="color: #0000FF;">(</span><span style="color: #000000;">s</span><span style="color: #0000FF;">)</span> <span style="color: #008080;">end</span> <span style="color: #008080;">function</span>

and manually edit every single call, again so that any future (/temporary) changes are quick, easy & obvious.<br>

Also note the latter is compatible with p2js, whereas namespaces are not.

For example:

filter <methodCalled>

method <methodCalled> args {

puts ">>[xmpl calculate 2 3 5]<<"

oo::objdefine xmpl mixin InterceptAspect

{{out}}

>>22<<

Notice also that a client can still import the ''wrapped'' class via the ''wrapper'' module which enables it to call ''unwrapped'' methods without the need to import the ''wrapped'' module as well. To expand the Julia example a little:

class Adder {

static mul2(x) { x * 2 }

import "/adder" for Adder

return Adder.add2(x)

}

import "/logAspectAdder" for LogAspectAdder, Adder

var m = Adder.mul2(4)

System.print("3 + 2 = %(a)") // logged

{{out}}