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++.m oderated. First time posters: Do this! ]

[Jack Klein]

On 8 Feb 2004 19:48:44 -0500, "christophe r diggins"
<cd******@users .sourceforge.ne t> 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.l earn.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++.m oderated. 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++.m oderated. 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 "interleavi ng"
(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++.m oderated. First time posters: Do this! ]

[christopher diggins]

"Maciej Sobczak" <no*****@no.spa m.com> wrote in message
news:c0******** **@atlantis.new s.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 "interleavi ng"
(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++.m oderated. First time posters: Do this! ]

[christopher diggins]

"Phlip" <ph*******@yaho o.com> wrote in message
news:R4******** ***********@new ssvr16.news.pro digy.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++.m oderated. 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++.m oderated. First time posters: Do this! ]

[Nicola Musatti]

"Phlip" <ph*******@yaho o.com> wrote in message news:<R4******* ************@ne wssvr16.news.pr odigy.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++.m oderated. First time posters: Do this! ]

[Dave Boyle]

Jack Klein <ja*******@spam cop.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++.m oderated. 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++.m oderated. First time posters: Do this! ]