Aspect Oriented Programming techniques

[christopher diggins]

I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article, and also I would like to know whether I am
repeating some prior work.

Thanks in advance!

--
Christopher Diggins
yet another language designer
http://www.heron-language.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Jack Klein]

On 8 Feb 2004 19:48:44 -0500, "christopher diggins"
<cd******@users.sourceforge.net> wrote in comp.lang.c++:

I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article, and also I would like to know whether I am
repeating some prior work.

Thanks in advance!
I can't speak to the quality of the article itself, nor whether it
repeats prior work, as I haven't researched Aspect Oriented
Programming before, but I have an issue with the code sample.

The sample program on the page is quite useless for most of the C++
compilers in existence.
// This is a small application to illustrate aspect oriented programming techniques
// using only C++ (i.e. no language extensions or special pre-processors
Ok, but how does that rationalize with:
#include "stdafx.h"
.....and:
int _tmain(int argc, _TCHAR* argv[])

.....neither of the lines above is standard C++, and neither will
compile on most compilers out there. Or does "vanilla C++" mean
something else?

If you want to make the point that AOP is for standard C++, and is not
just some new Microsoft/Windows specific extension, I would suggest
you produce an example that actually is "vanilla C++" and not just
Visual C++ specific.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Phlip]

christopher diggins wrote:

I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article, and also I would like to know whether I am
repeating some prior work.

Before I read, I'l ask a question that commits me to work hard when reading:

If we can implement Aspectism in vanilla C++, doesn't that suggest that
Aspectism is a Pattern, not a Paradigm or an Orientation?

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Maciej Sobczak]

Hi,

christopher diggins wrote:

I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article

You state in this article that the technique uses only Standard C++.
To fully support this claim, it would be good to resign from #include
"stdafx.h", TCHAR and other Microsoft-related stuff. ;)

Anyway - the article got me thinking a bit and ask myself the following
question:

If I call this technique a "compile-time Decorator pattern", would it be
really wrong?
If not (ie. if there is some merit in stating that this is *just* a
Decorator pattern implemented staticly with the help of preprocessor),
then: what is reason to name it Aspect-Oriented Programming?

Note also that your technique uses more "wrapping" than "interleaving"
(that's why I tend to call it Decorator, not AOP) when composing
complete components.

I may be wrong in this Decorator vs. AOP comparison.

I think that AOP calls for some new approach to development, including
completely new language features, or maybe a separate language in
itself. Using macros to compose wrapped function calls is probably good
for adding instrumentation to code (logging, etc.), but as for "true"
AOP it is still insufficient.

These are just my thoughts and I will be more than happy to learn
others' opinions.

Thank you for sharing this text with the community,

--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[christopher diggins]

"Maciej Sobczak" <no*****@no.spam.com> wrote in message
news:c0**********@atlantis.news.tpi.pl...

Hi,

christopher diggins wrote:

I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article
You state in this article that the technique uses only Standard C++.
To fully support this claim, it would be good to resign from #include
"stdafx.h", TCHAR and other Microsoft-related stuff. ;)

I apologize for having been so Microsoft-centric. There is now a new version
that is more general.
Anyway - the article got me thinking a bit and ask myself the following
question:

If I call this technique a "compile-time Decorator pattern", would it be
really wrong?
I do not know what you mean by that. I am aware of a Decorator pattern but a
compile-time Decorator pattern is a new one.
If not (ie. if there is some merit in stating that this is *just* a
Decorator pattern implemented staticly with the help of preprocessor),
then: what is reason to name it Aspect-Oriented Programming?
Because it allows the separation and isolation of cross cutting concerns in
a reusable manner.
Note also that your technique uses more "wrapping" than "interleaving"
(that's why I tend to call it Decorator, not AOP) when composing
complete components.
AFAICT it interleaves with existing code just as well as AspectJ or
AspectC++ does. Do you see examples which contradicts this?
I may be wrong in this Decorator vs. AOP comparison.
There may be some truth to what you say, but the implementation does not
discount the technique used. I could make a very similar argument about
object oriented programming.
I think that AOP calls for some new approach to development, including
completely new language features, or maybe a separate language in
itself.
What do you base that statement on?
Using macros to compose wrapped function calls is probably good
for adding instrumentation to code (logging, etc.), but as for "true"
AOP it is still insufficient.
There are many examples of how the proposed crosscutting macro could be used
: exception handling (not fully implemented as shown but trivial to add),
call prevention, testing of class invariants, introduction of preconditions
and postconditions, thread synchronization, real time constraints, resource
allocation / deallocation, etc. See
http://www.heron-language.com/aspect-programming.html for some more
examples, Heron uses a similar technique to the one proposed for C++.

I would like to see you back up the statement about insufficiency for AOP.
These are just my thoughts and I will be more than happy to learn
others' opinions.

Thank you for sharing this text with the community,

My pleasure.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[christopher diggins]

"Phlip" <ph*******@yahoo.com> wrote in message
news:R4*******************@newssvr16.news.prodigy. com...

christopher diggins wrote:

I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article, and also I would like to know whether I am
repeating some prior work.
Before I read, I'l ask a question that commits me to work hard when

reading:
If we can implement Aspectism in vanilla C++, doesn't that suggest that
Aspectism is a Pattern, not a Paradigm or an Orientation?

IMHO no.

--
Christopher Diggins
http://www.heron-language.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Dave Harris]

ph*******@yahoo.com (Phlip) wrote (abridged):

If we can implement Aspectism in vanilla C++, doesn't that suggest
that Aspectism is a Pattern, not a Paradigm or an Orientation?

We can implement object orientation in plain C, by juggling pointers
to functions by hand. Does that mean object orientation is a Pattern?

-- Dave Harris, Nottingham, UK

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Nicola Musatti]

"Phlip" <ph*******@yahoo.com> wrote in message news:<R4*******************@newssvr16.news.prodigy .com>...
[...]

Before I read, I'l ask a question that commits me to work hard when reading:

If we can implement Aspectism in vanilla C++, doesn't that suggest that
Aspectism is a Pattern, not a Paradigm or an Orientation?

Well, if you consider that it's orthogonal to Object Orientation... ;-)

Cheers,
Nicola Musatti

P.S. Sorry, I couldn't resist :-)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Dave Boyle]

Jack Klein <ja*******@spamcop.net> wrote in message news:<k5********************************@4ax.com>. ..

<snip>

#include "stdafx.h"

....and:

int _tmain(int argc, _TCHAR* argv[])

....neither of the lines above is standard C++, and neither will
compile on most compilers out there. Or does "vanilla C++" mean
something else?

<snip>

#include "stdafx.h" isn't standard C++? Why not?

Cheers,

Dave

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[John Kewley]

> Before I read, I'l ask a question that commits me to work hard when
reading:

If we can implement Aspectism in vanilla C++, doesn't that suggest that
Aspectism is a Pattern, not a Paradigm or an Orientation?

So if we can implement a functional program in vanilla C++, does that
suggest FP is a Pattern or a paradigm?

Why do you suggest that just because we can implement something in C++ that
it must be a pattern rather than a paradigm?

JK

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Helium]

> Before I read, I'l ask a question that commits me to work hard when reading:

If we can implement Aspectism in vanilla C++, doesn't that suggest that
Aspectism is a Pattern, not a Paradigm or an Orientation?

So object orientation isn't a paradigm, as we can do it in C++? What
about the procedural "paradigm" (which isn't a paradigm as we can do
itin C++). ...

So there is only one paradigm, called C++?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Helium]

Hm someonw mentioned that you used int _tmain ... (this strange MSVC7
extension). Now you use void main, which is as bad. Could you please
use int main, so it works on ISO-compatible compilers and not only on
those which allow the void main extension?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Claudio Puviani]

"Dave Harris" <br******@cix.co.uk> wrote

We can implement object orientation in plain C, by juggling pointers
to functions by hand. Does that mean object orientation is a Pattern?

Actually, it is. C programmers may not have called it that since neither "OOP"
nor "patterns" had become a buzzword before C++, but when OOP techniques were
used in C, it was basically just the application of an informal pattern (and
they were used in C way before C++ existed). And a paradigm IS a pattern. Most
people use the alternate definition: "a set of assumptions, concepts, values,
and practices that constitutes a way of viewing reality for the community that
shares them, especially in an intellectual discipline", but by that definition,
a lot of things we view as patterns are also paradigms.

Whether you see aspect-oriented programming as a pattern or as a paradigm
(second definition), depends a lot on whether you're married to the ideal or
just see the thing as yet another tool in your toolchest. Personally, I see it
as just another tool, and not one that needs special language features, but hey!
Every trend has its religious adherents ;-)

Claudio Puviani

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Phlip]

John Kewley wrote:

Before I read, I'l ask a question that commits me to work hard when reading:

If we can implement Aspectism in vanilla C++, doesn't that suggest that
Aspectism is a Pattern, not a Paradigm or an Orientation?

So if we can implement a functional program in vanilla C++, does that
suggest FP is a Pattern or a paradigm?

Why do you suggest that just because we can implement something in C++

that it must be a pattern rather than a paradigm?

A poster to news:comp.object frequently promotes a paradigm called "table
oriented programming". TOP might mean placing data in normalized tables and
solving problem by traversing their links and executing code pointers in
each table row. I don't see why this isn't just the "polymorphic array"
pattern.

Similarily, another poster gave the whimsical title "Pool oriented
programming" to a model of a comic book store, where all sales items inherit
a common Stock item, but each individual item has behaviors from "pools" of
item types. So a Comic Book derivative item would have a GetPageCount method
common to all objects in its pool, but a CD derivative would have a
GetTotalPlayingTime() method.

I suggested that given a Comic Book object, it can behave like a member of
the pools "C", "Comic Books", "Books", "Periodicals", etc. But this does not
mean the behavior must be >inside< the Comic Book object. That object could,
for example, contain a pointer to an array of objects that obey the
Flyweight Design Pattern. When asked to behave like a "Book" object, the
Comic Book object would find the "Book" entry in this list, if any, and pass
its state into that object's "doSomething()" method.

If the root principle of OO is polymorphism, then do any programming
orientations of "table", "pool", or "aspect" require a root principle that
one cannot reconstruct using our built-in language support for polymorphism?

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Phlip]

christopher diggins wrote:

I have written an article on how to do Aspect Oriented Programming in
vanilla C++ (i.e. without language extensions or other tools such as
AspectC++). The article is available at
http://www.heron-language.com/aspect-cpp.html. I would appreciate some
feedback on the article, and also I would like to know whether I am
repeating some prior work.

I looked at the source code, in terms of solving a problem found on
news:comp.object , under the name "Pool oriented programming".

The poster wanted to model a comic book store, where all sales items inherit
a common Stock item, but each individual item has behaviors from "pools" of
item types. So a Comic Book derivative item would have a GetPageCount method
common to all objects in its pool, but a CD derivative would have a
GetTotalPlayingTime() method.

The OP uses "pool" to mean a venn diagram of abilities, with overlaps.

Here's a basic object from your sample:

class CPoint {
public :
CPoint() { SetXY(0, 0); };
CPoint(const CPoint& pt) { SetXY(pt.GetX(), pt.GetY()); };
CPoint(int x, int y) { SetXY(x, y); };
virtual int GetX() const { return mX; };
virtual int GetY() const { return mX; };
virtual void SetX(int x) { mX = x; };
virtual void SetY(int y) { mY = y; };
virtual void SetXY(int x, int y) { SetX(x); SetY(y); };
virtual void FuBar() { };
private :
int mX, mY;
};

I don't see how to solve either the pool oriented programmer's problem, or
my potential solution, using this system. It appears I would need to add a
method to a basic object for each of its aspects, whether an object
containing only the intersection of all aspects can support that method or
not.

My thinking may lack some orthogonal dimension here.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Maciej Sobczak]

Hi,

christopher diggins wrote:

If I call this technique a "compile-time Decorator pattern", would
it be really wrong?
I do not know what you mean by that. I am aware of a Decorator pattern
but a compile-time Decorator pattern is a new one.

Well, I may be wrong with this comparison, but consider this:

http://www.dofactory.com/patterns/PatternDecorator.aspx

and in particular, the definition:

"Attach additional responsibilities to an object dynamically."

I understand that the merit of Decorator pattern is to provide non-invasive
extension to some operation, where "atomicity" of the original operation is
preserved. In other words, we "decorate" some operation with the means of
providing some pre- and post-operations and not by introducing anything in
the middle of the original operation, to which we may have no access. The
dynamic part means that polymorphism is used as a composition tool, allowing
us to change the decorations at runtime.
I found your technique to be similar and at the same time different in that:
- it composes operations with the means of providing pre- and
post-operations (or in other words on-entry and on-exit blocks); the
operations themselves are still black-box entities
- it does it at compile-time, meaning that once the composition is specified
and compiled, it cannot be later changed.

This is why I called it a compile-time Decorator.

> If not (ie. if there is some merit in stating that this is *just* a
Decorator pattern implemented staticly with the help of

preprocessor), > then: what is reason to name it Aspect-Oriented

Programming?
Because it allows the separation and isolation of cross cutting
concerns in a reusable manner.
As do other techniques, where nobody bothered to put them into the now
trendy AOP bandwagon.
Consider the policy-based class design. I found it to be much more powerful
and expressive, but never seen it directly called AOP.
But see below.

> Note also that your technique uses more "wrapping" than "interleaving"
> (that's why I tend to call it Decorator, not AOP) when composing >

complete components.

AFAICT it interleaves with existing code just as well as AspectJ or
AspectC++ does. Do you see examples which contradicts this?

No, there is no need for contradiction.
The wrapping means that the composition of different "aspects" looks like
onion ("ogres are like onions" ;) ):

logging(on-entry)
synchro(on-entry)
memory_mgmt(on-entry)
...
operation
...
memory_mgmt(on-exit)
synchro(on-exit)
loggin(on-exit)

The "preventive" aspect still falls into this, as having only the on-entry
part.

This is wrapping. The interleaving, as I understand, it may look like this:

logging(part1)
synchro(part1)
...
logging(part2)
memory_mgmt(part1)
synchro(part2)
operation(part1)
memory_mgmt(part2)
operation(part1)
synchro(part3)
...
logging(part3)
memory_mgmt(part3)
loggin(part4)

See? The composition of different aspects leads to some code transformations
and building onion-like structures is only one, probably the simplest
possible transformation. In general, the transformations required to compose
different aspects can be arbitrary.

It may be possible to decompose the code into pieces in a way that will lead
to onion-like structures (where everything is based on on-entry and on-exit
blocks), but such decomposition of the main program logic would be
problematic in the sense that it would be needed *only* to bend to this
particular composition technique and may spoil the initial design.

Moreover, code can be transoformed even to the extent that cannot be
expressed as moving around complete statements.

Consider, for example, that your application prints some output and one of
the *aspects* of your design is the case (lowercase/uppercase/mixed) of this
output or whether the numbers are roman or arabic, or how strings should be
compared, considering the character encoding and other localization-related
stuff used.

Another aspect may be the optimisation mode. The program can minimize DB
accesses (with the use of local caching structures) or minimize the memory
usage. This acpect may have influence on many points in the program,
possibly scattered across the whole project. Moreover, this aspect may be
bound at compile-time or at run-time and the binding time also influences
the way it is implemented.

Some aspects may not be even expressible in terms of classes or functions,
for example the compile-time optimization. The program may be optimized for
speed or for size and I may wish to bind this aspect differently for
different parts of the project.

All these exaples mean that wrapping calls with the means of on-entry and
on-exit blocks is only a single tool, probably the simplest one. The problem
is that other tools are not necessarily in the same box.

> I think that AOP calls for some new approach to development,

including > completely new language features, or maybe a separate
language in > itself.

What do you base that statement on?

[...] I would like to see you back up the statement about insufficiency for

AOP.

I base it on the above examples.

At the moment, I have to use different techniques for aspect specification
and different techniques for composition. I can use compile-time wrapping,
policy-based class design, design patterns, message filters and
interceptors, compiler switches, makefiles, and everything else, but they
are all very loosely coupled, if coupled at all. There is no clear relation
between, for example, the makefile settings, the Strategy pattern in the
middle of the project and the locale facet imbued in the single stream
object, even if they all serve the same aspect.
What I want is the possibility to specify and manage aspects in the
consistent way, no matter what technique is later used to implement and
compose aspects (or whether this is done automatically). Whether it is some
meta-language, language extension or sophisticated GUI tool, it needs to be
consistent.

The loosely coupled bunch of techniques and approaches is only an indication
that the community matures to further research, but there is still nothing
that I would call a *paradigm*.

These are just my thoughts and I will be more than happy to learn
others' opinions.

--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]