«

Hello,

Aspect oriented Software development seems to be expanding in the
popular vision of developers, with more and more IDE 'add-ons' and
even more specialized tools,Jboss etc.
I've seen more and more languages integrate AOP,AspectJ (Java),
AspectR(Ruby)etc.Aspect oriented does seem to be the place to go from
a developer standpoint.What I want to know is,if anybody on a
commercial scale is using AOSD to develop commercial products? Is an
Open Source development ever going to gain the trust of industry? It
may be ok for personal projects and other Open Source material but
will your bank ever accept it? Is it the fact that AOP is new and, for
most,confusing or is it the fact that AOP has developed in the
environment it has.i.e Open Source,that may dissuade commercial
development shops from accepting AOP.

What are the main features that may lead to AOSD adoption? Is AOP the
next step on from OOP? Is it another chance for some of the lesser
utilised languages to step up to Java and C++? Your opinions on the
subject would be appreciated? Design features are one thing but
widespread adoption is another, or is it?

Anything you care to add on the subject would be appreciated on this
short questionnaire.
http://www.geocities.com/aspect505

Thank you for your participation.


Shane Hassan.


http://www.geocities.com/aspect505

Wow someone actually uses this group!

--
Stan

On Sat, 23 Aug 2003 08:54:04 +0900
Mark Wilson <> wrote:
<snip>
> I have yet to read a description of what aspect oriented development
> is and how one would use it, that I could understand (i.e., with a
> code example that explains what is being done). Could someone provide
> such a description?

Search RAA for aspectr. I don't think it's maintained, but the code is
interesting.

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

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.

> [ (New_aspect)]
> Aspect oriented Software development seems to be expanding ...
> ...some of the lesser
> utilised languages to step up to Java and C++?

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.

We make our new hires give a brief presentaion on some technology as part
of the interview process. In our last hiring binge we used AOP as the
principle topic. It lets us see the communication skills of the prospect
and it also allows us a glimpse into areas none of us have time to pursue.

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.

Since then I have seen a couple of articles in Software Development
Magazine (online version) suggesting that AOP is no longer as "cool" as it
used to be. With OOP it is fairly obvious that it reduces the complexity of
the software process and if used correctly it is fairly easy to explain.
With AOP there is no single, simple overview of the technology.

On Sat, 23 Aug 2003 22:00:22 +0900, Lothar Scholz <> wrote:

>> Aspect oriented Software development seems to be expanding in the
>> popular vision of developers, with more and more IDE 'add-ons' and
>> even more specialized tools,Jboss etc.
>
> 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.
>
>



--

Steven Ketcham <> wrote in message
> 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 <> wrote:
> > 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.

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

On Wed, 27 Aug 2003 12:09:46 +0900
(Hung Jung Lu) wrote:
<snip>

Great post. This explains the purpose of AOP better than I have ever
seen it expressed. Thank you.

Hung Jung Lu wrote:
<snip>

Thanks for the post Hung, very interesting. Could you recommend a link
or two for more info?

Michael

Jason Williams <> wrote in message news:<. org.uk>...
> In article < >, Hung Jung Lu wrote:
> > 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.
>
> Eh? What's wrong with;
>
> def methodThatHasToListenForAnEvent
> listenForEvent(e) do
> # The method stuff goes here
> end
> end

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_government_bond():
....
else:
....
if self.is_domestic():
....
else:
....
#--------------- step 2 during calculation
code shared under all circumstances
#--------------- step 3 during calculation
if self.has_fixed_rate():
....
else:
....
if self.is_domestic():
....
else:
....
#--------------- step 4 during calculation
code shared under all circumstances
#--------------- step 5 during calculation
if self.is_domestic():
....
else:
....
if self.is_government_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_bond(),
has_fixed_rate() features, (e.g: have a subclasses like
domestic_fixed_rate_government_bond
foreign_variable_rate_corporate_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