Aspect oriented Everything?

**Trent Curry** · Jul 18 '05, 01:54 AM

Re: Aspect oriented Everything?

Wow someone actually uses this group!

--
Stan

**Lothar Scholz** · Jul 18 '05, 01:55 AM

Re: Aspect oriented Everything?

> Aspect oriented Software development seems to be expanding in the[color=blue]
> popular vision of developers, with more and more IDE 'add-ons' and
> even more specialized tools,Jboss etc.[/color]

I'm not sure if this is a the way to go. I've only seen proof of
concept but no real use. But only in the latter case you can see the
problems.

I don't like it because it breaks encapsulation and splitters the code
over a few files. Maybe that can be solved with new kind of editors
but it is much more easy to result in a big confusion.

The most important use cases that i've seen so far are:

- Logging facilities
- Debugging code
- Pre/Postconditions
- Threading synchronization

1+2+3 can be embedded in a language. This is already done in Eiffel.
I don't know if i really want to see something as difficult as
"threading synchronization " as an aspect.

**Lothar Scholz** · Jul 18 '05, 01:55 AM

Re: Aspect oriented Everything?

> Aspect oriented Software development seems to be expanding in the[color=blue]
> popular vision of developers, with more and more IDE 'add-ons' and
> even more specialized tools,Jboss etc.[/color]

I'm not sure if this is a the way to go. I've only seen proof of
concept but no real use. But only in the latter case you can see the
problems.

I don't like it because it breaks encapsulation and splitters the code
over a few files. Maybe that can be solved with new kind of editors
but it is much more easy to result in a big confusion.

The most important use cases that i've seen so far are:

- Logging facilities
- Debugging code
- Pre/Postconditions
- Threading synchronization

1+2+3 can be embedded in a language. This is already done in Eiffel.
I don't know if i really want to see something as difficult as
"threading synchronization " as an aspect.

**Will Stuyvesant** · Jul 18 '05, 01:56 AM

Re: Aspect oriented Everything?

> [letterbox1001@h otmail.com (New_aspect)][color=blue]
> Aspect oriented Software development seems to be expanding ...
> ...some of the lesser
> utilised languages to step up to Java and C++?[/color]

How about stepping from Java or C++. AOP is just a contrived way to
get around the static typing restrictions that Java and C++ have. You
need Python.

--
I fear explanations explanatory of things explained.

**Will Stuyvesant** · Jul 18 '05, 01:56 AM

Re: Aspect oriented Everything?

> [letterbox1001@h otmail.com (New_aspect)][color=blue]
> Aspect oriented Software development seems to be expanding ...
> ...some of the lesser
> utilised languages to step up to Java and C++?[/color]

How about stepping from Java or C++. AOP is just a contrived way to
get around the static typing restrictions that Java and C++ have. You
need Python.

--
I fear explanations explanatory of things explained.

**Hung Jung Lu** · Jul 18 '05, 02:02 AM

Re: Aspect oriented Everything?

Steven Ketcham <stedak@charter .net> wrote in message[color=blue]
> AOP was very difficult to explain, debug and implement. It did not
> obviously replace any of our current procedures and at best it was
> perceived as very heavy-weight. The conclusion on AOP was that it was a
> neat concept but there was no immediate benefit for using it.
>
> On Sat, 23 Aug 2003 22:00:22 +0900, Lothar Scholz <llothar@web.de > wrote:[color=green]
> > I don't like it because it breaks encapsulation and splitters the code
> > over a few files. Maybe that can be solved with new kind of editors
> > but it is much more easy to result in a big confusion.[/color][/color]

AOP is the latest effort in code factorization. Code factorization
started with the goto statement, then loops, then functions, then
classes and methods. And now, AOP.

If you write programs in OOP long enough, you will realize that there
are code spots that are not factorized. For example, you register to a
event listener at the beginning and de-register at the end of a
method. If you find yourself writing very similar codes in various
classes or methods all over places, you are not factoring your code
efficiently. It's not your fault, it's just that OOP cannot do certain
types of code factorization.

Before having loops, a repetitive task may look like

x = x + 1
x = x + 1
x = x + 1

But when you have loops, you can factor the three lines of code into

for i in range(3):
x = x + 1

Similarly, before object-oriented programming, you have data structure
that are very similar, say, A and B, A has (color, shape) and B has
(color, shape, weight), with OOP you can use inheritance, and factor
out the common code.

If we view OOP and inheritance as a vertical dimension in code
factorization, AOP would be a new horizontal dimension in code
factorization. Hence, people use terms like "aspect weaving".

Some people don't like AOP because it violates encapsulation in the
vertical dimension. But this way of thinking is kind of, erh,
unidimensional. Because conversely, a program that is built from
purely AOP is encapsulated in its own aspect dimension, and the usage
of OOP in that case would violate the encapsulation in the horizontal
dimension. The fact is, both factorizations are needed in the real
world. Aspect-oriented coding and object-oriented coding are like the
conjugate variables in quantum mechanics, whether you use one picture
or the other, at the end of the day they are equivalent, but in some
circumstances it's better to use one than the other. (If you know
Fourier transform, you know what I mean. A localized wave packet in
time necessarily means a spread-out packet in frequency, and
vice-versa. You can't have encapsulation both ways.)

regards,

Hung Jung

**Hung Jung Lu** · Jul 18 '05, 02:03 AM

Re: Aspect oriented Everything?

Jason Williams <jason@jasonand ali.org.uk> wrote in message news:<slrnbkot3 p.1d5.jason@kot u.jasonandalish ouse.org.uk>...[color=blue]
> In article <8ef9bea6.03082 61857.1b44a5b7@ posting.google. com>, Hung Jung Lu wrote:[color=green]
> > If you write programs in OOP long enough, you will realize that there
> > are code spots that are not factorized. For example, you register to a
> > event listener at the beginning and de-register at the end of a
> > method.[/color]
>
> Eh? What's wrong with;
>
> def methodThatHasTo ListenForAnEven t
> listenForEvent( e) do
> # The method stuff goes here
> end
> end[/color]

The question is: are there code spots that are not factored? If you
have ONE single class that has to implement the before, around, or
after methods, sure, nothing wrong with what you have said. But, if
you have

class A:
def f1():
register()
...
deregister()
class B:
def f2():
register()
...
deregister()
class C:
def f3():
register()
...
deregister()

You start to ask your self: how come the register() deregister() parts
are not factor out? How can I factor out these parts of code?

Why do you want to factor them out? You may ask. Because sometimes
later, you may realize that, heh, actually you want to do one more
thing before calling f1() f2() f3(): at beginning of the calls you
want to log the method call. If you don't have AOP, you would have to
manually modify each class into:

class A:
def f1():
log()
register()
... non-factorizable code specific to f1
deregister()
class B:
def f2():
log()
register()
... non-factorizable code specific to f2
deregister()
class C:
def f3():
log()
register()
... non-factorizable code specific to f3
deregister()

And later, you find out that you want to catch an certain type of
exception and respond properly, without AOP, you go back to your code
and write something like:

class A:
def f1():
try:
log()
register()
... non-factorizable code specific to f1
deregister()
except:
...
class B:
def f2():
try:
log()
register()
... non-factorizable code specific to f2
deregister()
except:
...
class C:
def f3():
try:
log()
register()
... non-factorizable code specific to f3
deregister()
except:
...

And then you realize that, oh, when the exception happens, you need to
do some clean up, then you go back to your code and do

class A:
def f1():
try:
log()
register()
... non-factorizable code specific to f1
deregister()
except:
...
finally:
...
class B:
def f2():
try:
log()
... non-factorizable code specific to f2
...
deregister()
except:
...
finally:
...
class C:
def f3():
try:
log()
register()
... non-factorizable code specific to f3
deregister()
except:
...
finally:
...

And then, someone tells you that they want to know the time spent in
these methods, so you do:

class A:
def f1():
start_timer()
try:
log()
register()
... non-factorizable code specific to f1
deregister()
except:
...
finally:
...
end_timer()
class B:
def f2():
start_timer()
try:
log()
... non-factorizable code specific to f2
...
deregister()
except:
...
finally:
...
end_timer()
class C:
def f3():
start_timer()
try:
log()
register()
... non-factorizable code specific to f3
deregister()
except:
...
finally:
...
end_timer()

And it is at this point that you start to wonder, man, it's tedious
and error-prone trying to do the something to all the classes that
share similar functionalities . And at the moment, you start to wonder
whether you can factor out the similarities. Notice that OOP or class
inheritance will not allow you to factor out these types of
"horizontal common code spots". A way to see it is to have three
sheets of paper, and you write the code of class A, B, C on each
sheet, and stack the three sheets together. The common areas that
overlap are in a horizontal direction. This type of horitontal
factorization is what AOP is all about. Once you factor out the common
parts, you can modify the code spot just once, and it will be applied
automatically to all your classes.

To my, horizontal factorization is what AOP is all about. It goes
beyond the before-, around-, after- hooks. I've written codes where I
have many if statements in a base class method:

def f():
#--------------- step 1 during calculation
code shared under all circumstances
#--------------- step 1 during calculation
if self.has_fixed_ rate():
....
else:
....
if self.is_governm ent_bond():
....
else:
....
if self.is_domesti c():
....
else:
....
#--------------- step 2 during calculation
code shared under all circumstances
#--------------- step 3 during calculation
if self.has_fixed_ rate():
....
else:
....
if self.is_domesti c():
....
else:
....
#--------------- step 4 during calculation
code shared under all circumstances
#--------------- step 5 during calculation
if self.is_domesti c():
....
else:
....
if self.is_governm ent_bond():
....
else:
....

After writing so many if...else... statement, you start to wonder: can
I factor out these if...else... statements? One way is to use OOP and
subclasses to encapsulate the is_domestic(), is_government_b ond(),
has_fixed_rate( ) features, (e.g: have a subclasses like
domestic_fixed_ rate_government _bond
foreign_variabl e_rate_corporat e_bond, etc.), but in OOP you will find
out that common steps 1,2,4 will not be factored out, and that when
you need to change the code in the common steps, you need to change in
all subclasses, which is tedious and error-prone. Worse, with 3
features you have a combination of 8 subclasses, and if one day you
include one more feature, you will have 16 subclasses. Are you going
to change the code manually in 16, 32, 64 classes? Clearly inheritance
is not the way to implement properties/features like these ones. OOP
just cannot solve the problem.

It is only when you run into this kind of situations, that you start
to think about code factorization in a different dimension.

AOP is a really need. I would agree that it is still an immature field
of research. But people really need it.

Hung Jung

**Andrew Dalke** · Jul 18 '05, 02:03 AM

Re: Aspect oriented Everything?

Hung Jung Lu:[color=blue]
> The question is: are there code spots that are not factored? If you
> have ONE single class that has to implement the before, around, or
> after methods, sure, nothing wrong with what you have said. But, if
> you have
>
> class A:
> def f1():
> register()
> ...
> deregister()
> class B:
> def f2():
> register()
> ...
> deregister()
> class C:
> def f3():
> register()
> ...
> deregister()
>
> You start to ask your self: how come the register() deregister() parts
> are not factor out? How can I factor out these parts of code?[/color]

What about
[color=blue][color=green][color=darkred]
>>> class RegisterFunc(ob ject):[/color][/color][/color]
.... def __init__(self, f):
.... self.f = f
.... def __get__(self, obj, type = None):
.... return RegisterCall(se lf.f, obj)
....[color=blue][color=green][color=darkred]
>>> class RegisterCall(ob ject):[/color][/color][/color]
.... def __init__(self, f, obj):
.... self.f = f
.... self.obj = obj
.... def __call__(self, *args, **kwargs):
.... register()
.... try:
.... self.f(self.obj , *args, **kwargs)
.... finally:
.... deregister()
....[color=blue][color=green][color=darkred]
>>> def register():[/color][/color][/color]
.... print "Register"
....[color=blue][color=green][color=darkred]
>>> def deregister():[/color][/color][/color]
.... print "Deregister "
....[color=blue][color=green][color=darkred]
>>> class Spam(object):[/color][/color][/color]
.... def spam(self):
.... print "I've been spammed!"
.... spam = RegisterFunc(sp am)
....[color=blue][color=green][color=darkred]
>>> Spam.spam()[/color][/color][/color]
Register
I've been spammed!
Deregister[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

[color=blue]
> If you don't have AOP, you would have to manually modify each class into:[/color]
...[color=blue]
> Notice that OOP or class
> inheritance will not allow you to factor out these types of
> "horizontal common code spots".[/color]

Hmm. Given that, is what I'm doing above not OO programming?
You can derive from it, and because the methods are not changed
once the class is defined, I event get the proper behaviour that
the childrens' behaviour is more restrictive than the parent's.

(I point this out because pre-2.3 I would have used __getattr__
hooks to make a wrapper around the whole class, rather than
a per-method one like I did here.)
[color=blue]
> To my, horizontal factorization is what AOP is all about. It goes
> beyond the before-, around-, after- hooks. I've written codes where I
> have many if statements in a base class method:[/color]
...[color=blue]
> but in OOP you will find
> out that common steps 1,2,4 will not be factored out, and that when
> you need to change the code in the common steps, you need to change in
> all subclasses, which is tedious and error-prone.[/color]

For this I would usually use a mixin or just call a function. Or
change it so there are functions which can each modify a state,
as in

class Modifier:
def between_1_and_2 (self, state):
..
def between_2_and_3 (self, state):
..

class FixedRateModifi er(Modifier):
...
class GovernmentBondM odifier(Modifie r):
...

def f(arg1, arg2, arg3, ...):
modifiers = [FixedRateModifi er(), GovernmentBondM odifier()]
state = State(arg1, arg2, arg3)
do_step1_calcul ations(state)

for m in modifiers:
m.between_1_and _2(state)

self.do_step2_c alculations(sta te)

for m in modifiers:
m.between_2_and _3(state)

...

Is this a hand-written way of doing AOP? (I wouldn't be surprised.
I didn't understand OO until I handwrote a system using typedefs
and lots of function pointers.)

[color=blue]
> Clearly inheritance
> is not the way to implement properties/features like these ones. OOP
> just cannot solve the problem.[/color]

Agreed about the inheritance part. Disagree that there are non-AOP
ways to address it.

Andrew
dalke@dalkescie ntific.com

**Andrew Dalke** · Jul 18 '05, 02:03 AM

Re: Aspect oriented Everything?

Hung Jung Lu:[color=blue]
> (If you know
> Fourier transform, you know what I mean. A localized wave packet in
> time necessarily means a spread-out packet in frequency, and
> vice-versa. You can't have encapsulation both ways.)[/color]

But then there's wavelets.

:)

Andrew
dalke@dalkescie ntific.com

**Sascha Dördelmann** · Jul 18 '05, 02:04 AM

Re: Aspect oriented Everything?

letterbox1001@h otmail.com (New_aspect) wrote:[color=blue]
> What I want to know is,if anybody on a
> commercial scale is using AOSD to develop commercial products?[/color]

I know about AOP for quite a while now but I've actually never used it
in a commercial product.

One reason I can offer you is, that it was always easy to get around
using it. You know most of the "vertical" and "horizontal " needs from
the beginning of the project and are free to include them in your UML
model.

One strategy to get around AOP at design time ist multiple inheritance
(MI). Even if the language doesn't support MI directly there are many
ways to implement an UML model which includes MI. Other strategies
include the visitor pattern or some other form of delegation to
specialized objects.

There are some things which could make AOP more attractive:
- discussions like this one
- integration in some language would of course make some people use it
(but who would use this brand new language?)
- find a "killer app" (e. g. show that it's better to use AOP to
profile
than to use the standard profiling tools)
- make it either as simple as possible or very difficult but with
enormous power
- build a refactoring browser which refactors aspects to where they
belong
;-)

Generic programming is gaining more and more attention in the world of
statically typed languages. AOP could be part of that. On the other
hand it's a lot easier to implement AOP in a dynamic language like
Ruby. And as people like the nature of their favorite language, they
might like the dynamic aspect of AOP, too.

Cheers
Sascha

**David Abrahams** · Jul 18 '05, 02:05 AM

Re: Aspect oriented Everything?

hungjunglu@yaho o.com (Hung Jung Lu) writes:
[color=blue]
> (2) Yet another approach is using code templates, a la
> meta-programming. There are more complicated examples, like the second
> example in my previous posting, where it's not easily solved by one
> single code block, nor one single MixIn, nor by function composition.
> In that case one can assemble the code by using a template, and make
> successive pattern substitutions depending on the properties of the
> particular instrument. Of course, this approach is a bit beyond the
> reach of Java/C++, and anyway the strongly-typed language people would
> protest because your code may not have been properly verified by the
> compiler.[/color]

Don't lump Java and C++ together, please!

I am currently writing a book about metaprogramming in C++, using
(ahem) templates. I realize that you were referring to a more
abstract concept when you wrote "template", but it's still amusing
that the very C++ feature which implements your "template" is called
"template". Well, maybe I need more sleep. It's amusing to me
anyway.

Anyway, the compile-time computational power of C++ templates goes far
beyond simple templated code generation. In fact they have been shown
to be Turing-complete
(http://osl.iu.edu/~tveldhui/papers/2003/turing.pdf). And, as for
proper code verification, template metaprogramming doesn't compromise
type-safety.

Regards,
--
Dave Abrahams
Boost Consulting

https://www.boost-consulting.com

**Robert Will** · Jul 18 '05, 02:10 AM

Re: Aspect oriented Everything?

llothar@web.de (Lothar Scholz) wrote in message news:<6ee58e07. 0308230459.24f5 3b64@posting.go ogle.com>...[color=blue]
>
> I'm not sure if this is a the way to go. I've only seen proof of
> concept but no real use. But only in the latter case you can see the
> problems.
>
> I don't like it because it breaks encapsulation and splitters the code
> over a few files. Maybe that can be solved with new kind of editors
> but it is much more easy to result in a big confusion.
>
> The most important use cases that i've seen so far are:
>
> - Logging facilities
> - Debugging code
> - Pre/Postconditions
> - Threading synchronization
>
> 1+2+3 can be embedded in a language. This is already done in Eiffel.
> I don't know if i really want to see something as difficult as
> "threading synchronization " as an aspect.[/color]

I see, you watched the trend the closely. Incidentally I have the
same opinion, except that I don't consider their dysfunctional
examples as proof of concepts.

**Anton Vredegoor** · Jul 18 '05, 02:11 AM

Re: Aspect oriented Everything?

Clifford Heath <cjh_nospam@man agesoft.com> wrote:

<snip>
[color=blue]
>Proprietry standards for basic technologies are doomed.[/color]

Right. However the previous long piece of text lead me to read this
the exact opposite way of what is written above at first. Is this a
perceptual illusion trick or is it my bad? Never mind, all's well that
ends well :-)

Anton

**Clifford Heath** · Jul 18 '05, 02:13 AM

Re: Aspect oriented Everything?

Anton Vredegoor wrote:[color=blue][color=green]
>>Proprietry standards for basic technologies are doomed.[/color]
> Right. However the previous long piece of text lead me to read this
> the exact opposite way of what is written above at first.[/color]

:-). I believe in tools, and on re-reading I guess you thought I was
about to start spruiking some tool, and I *am* invoking tool-makers
to rise to the challenge. OTOH - they shouldn't expect money for it,
only glory :-).

Clifford.

Aspect oriented Everything?

Aspect oriented Everything?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment