Re: Raise of hands (virtually): How many here use AOP?

Chris, once again thanks for taking so much care in articulating your
thoughts on AOP. Remaining comments are in line.

Chris wrote:
On the other hand, mis-uses of AOP try to change the GOAL of
writing code, causing people to accept code that would have been
rejected otherwise.

Your comments are getting me light years ahead in considering what
might be abuses.

Put as an analogy: an index is quite helpful in using a book. However,
the index should not be used as an excuse for failing to organize the
book in a logical flow with related information grouped logically
together. Similarly, AOP programming aids should not be used as an
excuse for failing to organize code in such a way that control flow is
indicated in the source.

Agreed, as Aspects are part of the source. Other standard Java
techniques should be considered first, but not to the point of bending
over backwards to avoid AOP. Should really ask of AOP (annotions only)
and the clearest standard Java solution devised: "Which is clearer and
easier to maintain (with prejudice towards standard Java)?"

I think part of the misunderstanding is that I write "only if" and you
seem to have read that as "if and only if".

Guilty.

Let's say I throw an exception in some code, and Eclipse pops up a
little icon in the margin informing me that there's some AOP advice that
applies to this code. I click on the icon, and discover that the
exception I am throwing is going to be emailed to the development team
with its full stack trace in an automated bug report. I don't want that
to happen, so I have to go modify the pointcut and avoid it. This is
the "ideal" situation, in which I had all the tools to tell me exactly
what was going on, and they did their job.

OK, since I'm using Eclipse I'm assuming I have access to those tools.

Yet AOP was still extremely
far from harmless. Rather, it did the following:

1. Something that should have taken 15 seconds has now taken 100 times
as long.

Not sure why it would be such a large factor, but since I haven't used
AOP yet I defer to you.

2. Some single unit of code (the pointcut) is now accumulating a list of
places where non-logged exceptions are thrown. This is not useful
information, and its maintenance complicates management of the project.

This is assuming pattern matching right? (If so, ignore this next
question. If not, why can't you just remove or change an annotation?)

3. The logging code therefore becomes very unstable... as unstable as
the most unstable part of the project to which it applies.

I will need to ponder this for a while.

4. I become reluctant to throw exceptions in places where they might be
a good idea, because I don't want to deal with accidentally tripping
someone's checkpoint again.

Isn't that like being reluctant to modify a super class? If it's gotta
be done it's gotta be done.

We haven't just lost encapsulation; we've invented poor abstractions,
and then enforced them on everyone. Or, as the article said that I
originally posted, we have switched to a new language that sort of like
Java, but not really.

I think it is a smart thing to expand Java. If Java does not support
AOP and it does prove to be a major benefit in the long run then Java
will "die" (in the same sense that COBOL "died") and we all have to go
out and learn CLOS or something because a lot of people start writing
in it. If AOP proves to be more trouble than it's worth, then only the
AOP features of Java will die. It's the old railroad problem, they
thought of themselves as a railroad company rather than a
transportation company. Had they considered their real role then, when
they were at their financial peak, they could have expanded business
into trucking and air when those transportation "techniques" were
fledglings. Instead other companies sprang up and took too much of
their business away... once they lost that business they didn't have
the finances to expand. Instead they took a "that'll never happen"
stance.

I'm not saying you are taking that stance. You have said in a prior
post that you are "waiting for the moment..." and you certainly are
poised to go with a movement if one happens. I'm just saying AOP
intriguing-ly adds another dimension to programming and has to go
through the necessary growing pains to mature if it can. You may be
right it may just be current fashion like client-server was in the
early 90's until it was discovered how much workstation maintenance was
required on the fat clients. Companies that stuck with their mainframe
products died in the early 90's. Company's with client-server products
remembered that and in the late 90's saw the tides and migrated to the
web and survived. They suffered the growing pains to do it.

In this new language, which is used only in this
project.

Are you saying that each implementation of AOP is essentially defining
a new language that is project specific?

throwing an exception means two different things: control flow,
and logging. As an experienced Java developer, I feel confident writing
Java to work in someone's project... but I certainly don't feel
comfortable writing in this pseudo-Java. If I don't read through and
understand all the AOP stuff before writing ANY code for the project.

Doesn't that depend on how large your change is? If you are making a
minor change to the extent that you only need to understand the method
you are changing then you only need to understand the Aspects that are
involved in the method. Assuming you have acces to tools, which are
currently available, to point those out. If you are making a major
change to the extent that you have to understand the entire system then
you would potentially have to read much less code if AOP was, albeit,
*properly* implemented.

I
am reduced to the level of a programming novice who determines if code
is correct by compiling it... except I look for little AOP icons in the
margins of Eclipse instead.

I don't agree that this a novice-only technique. Sure, novices depend
on it for different reasons. I like to type fast and let the computer
worry about spelling. And I like when I click on a variable the IDE
color codes the same variable where it is also used. In the same way
I'm not adverse to letting the IDE point me to Aspects that will be
triggered.

(I keep using the exceptions example because I see it done a lot, and
it's horrid. Matching patterns of method names -- as in, add this code
every time I call a method starting with "test" -- is even worse, but I
think most people recognize the silliness of this and avoid it... most
of the time. Occasionally, though, I'm wrong in that last bit.)

Through this discussion I'm starting to see at least one problem with
pattern matching: It would cause me to consider naming objects and
methods such that Apsect patterns are simpler rather than naming them
for what they represent. Though another side of me wonders if they are
associated with the same aspects perhaps they should have similar
names... need to continue to ponder that.

Lets say you did, code
a cross-cutting concern into, say, 35 different classes pretty much all
the same code woven into those classes where appropriate. [...] And
another developer comes in and has to code a new requirement into the
cross-cutting concern.


[...]


Do you feel that the above error prone process is the lesser of the
evils here?


No, I feel that it's a straw man that is ridiculous to even consider.
It would be hard to come up with a programming technique that's NOT
better than what your hypothetical programmer is doing.

Let's get this straight. So he's got 35 copies of exactly the same
code, and yet he hasn't even bothered to factor that code out into a
utility method somewhere? What's wrong with him?!? I've certainly put
off work on code cleanliness to meet scheduling deadlines... but 35
copies?!? And he realizes that they are all copies, and he worries
about making sure they all stay in sink, and yet it's never occurred to
this guy that he ought to put this code in a function somewhere? The
solution to this problem is for the hypothetical programmer to leave his
job and enter the lucrative field of real estate management. They seem
to like his sort, there.

It's not 35 copies of the same code. It's 35 classes doing unique
functions that all also need to do one (or more) other same thing(s).
Yes, it is all factored to the max instantiating class variables
invoking methods as factoring allows. Inheritance is taken by another
concept and Interfaces can't be used because member properties are
required. So you have associations between classes to implement the
cross-cutting concern in standard Java. AOP can eliminate the
complexity of passing context around through method calls.

I don't mean to say that I never think AOP is useful. Occasionally, the
existing forms of abstraction available in modern programming languages
become awkward for certain problems, and AOP provides a convenient
solution.

Agreed, that's what I was trying to articulate in the 35 class example.

That said, the advantages are routinely and blatantly
overstated on a regular basis, and a large number of people need to come
back down to Earth and get back to doing their jobs instead of hyping
AOP.

Yeah, who doesn't brag about their children. Or their new truck.

Even if it's possible to make it work by detecting the bugs a
little earlier (which is essentially what an IDE plugin does), it's
still bad programming.

Even meeting all of your requirements it's still bad?



I'm unsure what you mean. I think I've made it continually clear that I
have no problem with AOP attached to things that have no other defined
purpose in the language; in other words, annotations -- which are sorta
defined by having no other defined purpose.

Yeah that's where communication breaks down here. You say it's ok
under the "annotations" condition, you have tools available to use
annotations, and then you say it's bad programming, so I don't know for
sure whether you were saying pattern matching techniques are bad or all
AOP techniques are still bad even when using annotations. As I write
this still I wonder if you are going to write something in response
that I will read one way and in another spot read the other way. Not
saying it's you.

It's the overloading of
significant language features that's problematic. Identifier names are
meant to be unique and communicate purpose to human beings, not to
define transaction semantics.

Yeah I agree and commented on that above.

Exceptions are used to quickly transfer
control from one bit of code to another; not to invoke logging. I just
can't imagine what could make someone think it's a good idea to be able
to make the behavior of a method change because its name starts with
some magic word...

(With all comments regarding concerns of pattern matching and benefits
of annotions in mind.) You are not changing the behavior of the method.
You are changing the behavior of the application. Except now the
method is stripped of everything except it's core function. You are
adding a dimension to the source code. Of course it all gets compiled
down to linear VM code in the end.

unless it's (a) an overwhelming desire to be on the
bandwagon for the next New Thing, (b) a lack of understanding of code
maintenance issues, or (c) a kind of twisted pleasure in setting land
mines for fellow programmers.

or (d) restricting code in Class methods to their core function and
code in Aspects to their core function improving readability.
or (e) reducing the amount of code

I asked in so many words in a prior post: Why are
these trade-offs not worth the benefits?


The main reason is that they are not necessary to achieve the benefits.

Neither are Interfaces, nor is Inheritance, nor loops. I mean shoot
you have to go all the way over into another source file (if you can
find it) to find out what is inherited. Better to just put all code
in-line then surely everyone will be able to read it. Oh wait. The
IDE makes navigation easy and organizes source into projects. I know.
That's extreme. I guess it comes down to perception of the value of
the benefits.

Why do you need to wait for others to know what you know? If the tools
already (seem to) support what you would like them do what's stopping
you from using them? Are you talking about your peers in your
organization? If so, are they using Eclipse as well, can you bring
them up to speed and catch unapproved techniques in peer reviews?


I certainly don't need to wait. However, a form of AOP that relies on
annotations instead of the existing hodgepodge of pointcut types and
patterns would be considerably more elegant in syntax and harder to get
screwed over with than the existing alternatives.

This is another one of those communication break downs. You say you
don't need to wait, but then you say AOP that relies on annotations
*would be* more elegant. Don't you mean *is* more elegant? It's here
today from what I read. Yes, pattern matching is still there, but as a
developer or organization you don't have to use features that rub the
wrong way. You establish guidelines and make sure everyone follows or
has a good case for pushing the boundaries.

.

Relevant Pages

  • ILC 2003: some impressions
    ... remarking that Scheme continuations have indefinite extent while in Lisp ... The idea of programming languages in general and Scheme in particular as ... presentation on Aspect Oriented Programming (AOP) was also fascinating. ... instantiation of AOP for Java) is in debugging. ...
    (comp.lang.lisp)
  • Re: Raise of hands (virtually): How many here use AOP?
    ... very nice features of development environments like Eclipse that do NOT ... mis-uses of AOP try to change the GOAL of ... I become reluctant to throw exceptions in places where they might be ... am reduced to the level of a programming novice who determines if code ...
    (comp.lang.java.programmer)
  • Re: Vancouver : Gregor Kiczales at Meetup.
    ... drewc wrote: ... > doing work with Aspect Oriented Programming (AspectJ). ... > He plans to talk mostly about AOP and AspectJ, but if i can get a few ...
    (comp.lang.lisp)
  • Re: when to use component-based design vs. stayign with traditional OOP
    ... I saw a presentation by Gregor Kiczales on Aspect-Oriented ... Aspect-oriented programming is a programming paradigm that ... Even though the primary functionality of each class is very different, ... AOP helps with logging and security which are archetypal cross-cutting ...
    (comp.object)
  • Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?
    ... > without writing a line of code. ... > A few months ago I had an introductory class on Java programming. ... Yeah, VB is what many people call a RAD language, for Rapid Application ... Java is very much NOT a RAD language; ...
    (comp.lang.cobol)
Loading