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]

Re: Aspect Oriented Programming techniques

On 8 Feb 2004 19:48:44 -0500, "christophe r diggins"
<cdiggins@users .sourceforge.ne t> wrote in comp.lang.c++:
[color=blue]
> 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![/color]

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.
[color=blue]
> // This is a small application to illustrate aspect oriented programming techniques
> // using only C++ (i.e. no language extensions or special pre-processors[/color]

Ok, but how does that rationalize with:
[color=blue]
> #include "stdafx.h"[/color]

.....and:
[color=blue]
> int _tmain(int argc, _TCHAR* argv[])[/color]

.....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/~ajo/docs/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]

Re: Aspect Oriented Programming techniques

christopher diggins wrote:
[color=blue]
> 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.[/color]

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?TestFirstUserInterfaces

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

[Maciej Sobczak]

Re: Aspect Oriented Programming techniques

Hi,

christopher diggins wrote:
[color=blue]
> 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[/color]

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]

Re: Aspect Oriented Programming techniques


"Maciej Sobczak" <no.spam@no.spa m.com> wrote in message
news:c07qst$kg2 $1@atlantis.new s.tpi.pl...[color=blue]
> Hi,
>
> christopher diggins wrote:
>[color=green]
> > 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[/color]
>
> 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. ;)[/color]

I apologize for having been so Microsoft-centric. There is now a new version
that is more general.
[color=blue]
> 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?[/color]

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.
[color=blue]
> 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?[/color]

Because it allows the separation and isolation of cross cutting concerns in
a reusable manner.
[color=blue]
> 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.[/color]

AFAICT it interleaves with existing code just as well as AspectJ or
AspectC++ does. Do you see examples which contradicts this?
[color=blue]
> I may be wrong in this Decorator vs. AOP comparison.[/color]

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.
[color=blue]
> I think that AOP calls for some new approach to development, including
> completely new language features, or maybe a separate language in
> itself.[/color]

What do you base that statement on?
[color=blue]
>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.[/color]

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.
[color=blue]
> 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,[/color]

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]

Re: Aspect Oriented Programming techniques

"Phlip" <phlip_cpp@yaho o.com> wrote in message
news:R4IVb.1997 3$2G6.18906@new ssvr16.news.pro digy.com...[color=blue]
> christopher diggins wrote:
>[color=green]
> > 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.[/color]
>
> Before I read, I'l ask a question that commits me to work hard when[/color]
reading:[color=blue]
>
> If we can implement Aspectism in vanilla C++, doesn't that suggest that
> Aspectism is a Pattern, not a Paradigm or an Orientation?[/color]

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]

Re: Aspect Oriented Programming techniques

phlip_cpp@yahoo .com (Phlip) wrote (abridged):[color=blue]
> If we can implement Aspectism in vanilla C++, doesn't that suggest
> that Aspectism is a Pattern, not a Paradigm or an Orientation?[/color]

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]

Re: Aspect Oriented Programming techniques

"Phlip" <phlip_cpp@yaho o.com> wrote in message news:<R4IVb.199 73$2G6.18906@ne wssvr16.news.pr odigy.com>...
[...][color=blue]
> 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?[/color]

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]

Re: Aspect Oriented Programming techniques

Jack Klein <jackklein@spam cop.net> wrote in message news:<k5ud2017g 2usf12flqcgbqjh isesge1g6s@4ax. com>...

<snip>
[color=blue][color=green]
> > #include "stdafx.h"[/color]
>
> ....and:
>[color=green]
> > int _tmain(int argc, _TCHAR* argv[])[/color]
>
> ....neither of the lines above is standard C++, and neither will
> compile on most compilers out there. Or does "vanilla C++" mean
> something else?[/color]

<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]

Re: Aspect Oriented Programming techniques

> Before I read, I'l ask a question that commits me to work hard when
reading:[color=blue]
>
> If we can implement Aspectism in vanilla C++, doesn't that suggest that
> Aspectism is a Pattern, not a Paradigm or an Orientation?[/color]

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! ]

[Helium]

Re: Aspect Oriented Programming techniques

> Before I read, I'l ask a question that commits me to work hard when reading:[color=blue]
>
> If we can implement Aspectism in vanilla C++, doesn't that suggest that
> Aspectism is a Pattern, not a Paradigm or an Orientation?[/color]

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

[Helium]

Re: Aspect Oriented Programming techniques

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

[Claudio Puviani]

Re: Aspect Oriented Programming techniques

"Dave Harris" <brangdon@cix.c o.uk> wrote[color=blue]
> We can implement object orientation in plain C, by juggling pointers
> to functions by hand. Does that mean object orientation is a Pattern?[/color]

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

[Phlip]

Re: Aspect Oriented Programming techniques

John Kewley wrote:
[color=blue][color=green]
> > Before I read, I'l ask a question that commits me to work hard when[/color]
> reading:[color=green]
> >
> > If we can implement Aspectism in vanilla C++, doesn't that suggest that
> > Aspectism is a Pattern, not a Paradigm or an Orientation?[/color]
>
> 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++[/color]
that[color=blue]
> it must be a pattern rather than a paradigm?[/color]

A poster to news:comp.objec t 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 "polymorphi c 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
GetTotalPlaying Time() method.

I suggested that given a Comic Book object, it can behave like a member of
the pools "C", "Comic Books", "Books", "Periodical s", 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 "doSomethin g()" 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?TestFirstUserInterfaces

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

[Phlip]

Re: Aspect Oriented Programming techniques

christopher diggins wrote:
[color=blue]
> 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.[/color]

I looked at the source code, in terms of solving a problem found on
news:comp.objec t , 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
GetTotalPlaying Time() 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?TestFirstUserInterfaces

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