Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews IT Technology

Aspect-Oriented Programming with AspectJ 496

Posted by timothy from the orient-your-object-aspect-please dept.
Verity Stob writes "There is a turning point in the emergence of a programming methodology. It doesn't matter how big and popular the website is, nor how many papers have been published in the ACM journals or development magazines, nor even whether the first conferences have been a sell-out. A methodology hasn't made really made it until somebody has published a Proper Book. With Aspect-Oriented Programming with AspectJ author Ivan Kiselev is bidding to drag AOP into the mainstream. He is motivated, he says in his introduction, by the recollection of the 25 odd years it took for the object-oriented concept to spread from its Simula origins in frosty Norway to being the everyday tool of Joe Coder. He aims to prevent this delay happening to AOP." Read on for Verity Stob's review of Kiselev's book.
Aspect-Oriented Programming with AspectJ
author Ivan Kiselev
pages 274
publisher SAMS
rating Excellent
reviewer Verity Stob
ISBN 0672324105
summary Introduction to a new programming technique using an extension to Java

He has divided the book into four parts. Part I provides a brief sketch of AOP and introduces its concepts. AOP builds on OOP, asserting that we need a new programming entity called, wait for it, an aspect. Mr Kiselev's explanation of aspects reminded me of that bit in The Hitchhiker's Guide to the Galaxy when the planet Golgafrincham divided its population into A types (who were the leaders, the scientists and the great artists), the C types (who were the people who did all the actual making of things and doing of things), and the B types, who comprised everybody left over: telephone sanitizers, advertising account executives and hairdressers. As I understand Mr Kiselev, the AOP view of things is that objects and classes (A type thinkers) and low-level procedures and APIs (C type doers) can be nicely encapsulated using traditional components. But aspects, software's little hairdressers, get their fingers into everything, and until now there has been no way to encapsulate them. This of course is what AOP in general and specifically the AspectJ superset of the Java language set out to do.

AspectJ's eponymous aspects are constructs not unlike ordinary classes. Mr Kiselev has not resisted the temptation to make an aspect Hello World example, and it looks reassuringly so-whatish:

package intro;

import java.io.*;

public aspect HelloWorldA
{
public static void main(String args[])
{
System.out.println(Hello, world!);
}
}

Mr Kiselev then lays out his stall of New Things. A join point is any point in execution flow that AspectJ can identify and -- to get slightly ahead of ourselves -- execute some extra code. The most frequently used kind of join point being the call to a method. Pointcuts specify collections of join points; as a regular expression is to an instance of matched text, so a pointcut is to a matching join point. An advice (with horrid plural 'advices') is the code to be executed when a given pointcut is matched. If you are familiar with Eiffel's pre- and post-conditions, then you'll understand if I say that it is common for advices to run in the same way, topping and/or tailing the execution of a method. The differences are that aspects are specified from outside the method without touching the method or its class's code, and that aspects can be applied to multiple methods in one go. Mr Kiselev concludes this section of the book with a few simplistic examples of 'here is class A, here is class B' kind.

In Part II Mr Kiselev rolls up his sleeves and takes us through an extended, realistic example. I did wonder if perhaps it weren't a wee bit too realistic, as it is a miniature website application for news story submission and reading -- sort of Slashdot Ultralite -- all done using JSP and a MySQL database. Just explaining this setup, without even using any AspectJ, consumes a 15-page chapter. Since I am a C++ programmer who has not had any contact with JSP, I was initially anxious that I might not be able to follow this. However, recalling that www.[name withheld].com, the clumsiest, ugliest corporate website on the Internet, is programmed in JSP, I reasoned that if the dolts that programmed that site could understand JSP then it couldn't be very hard. So it proved.

The first example comprises adding password protection to the application. This is achieved by adding an advice that intercepts calls to doStartTag() methods. The advice can test if the user is logged in and, if he isn't, throw an exception that will dump him back at the login page. (Who says exceptions aren't 21st century gotos?) At this point Mr Kiselev admits that the cute 10-line implementation that he initially shows is in reality a non-starter; for one thing not all pages that must be secured define doStartTag() methods, for another the aspect can't reach an instance variable it needs to read because it is declared in protected scope. The second problem is easily overcome. AOP offers a mechanism by which extra classes can be bodged ('introduced' is the preferred verb in the AOP community) into the hierarchy as parents of existing classes. He uses this to add an accessor method for the field in question. The other problem is not so neatly smothered, and it is somewhat ruefully that Mr Kiselev produces his final, two-page solution. But I think that it is greatly to Mr K's credit that he does this - it tastes like programming in the real world as I have experienced it.

For the rest of Part II, Mr K demonstrates other applications of AOP using the AspectNews code. This includes Eiffelish design-by-contract stuff, improved exception handling, various debugging and tuning techniques (specifically logging, tracing and profiling) and a chapter on runtime improvements - stream buffering, database connection pooling and result caching - which show the AOP way to do things, usually where I would expect to be putting in proxy classes.

In part III we get down and dirty with the AspectJ language. This is the part where the book explains the obscure stuff: how to make a pointcut that picks up object preinitialization, or make an advice that goes off only when you are exiting a method on the back of an exception. I skimmed this bit - I guess it will become vital when I start using AspectJ in earnest. It looked good and clear on a flick through. A brief part IV contains some patterns, to give one a start when engaging AspectJ in earnest. Apparently it is horribly easy to create infinitely recursive situations, so if you here a faint popping sound from your machine it will be the stack colliding with the heap. There are seven appendices, supplying such things as a summary of the API in AspectJ's packages and hints on obtaining and using the Open Source supplementary tools mentioned in the book (Tomcat JSP container, MySQL database and Ant make replacement). AspectJ itself, now escaped from Xerox PARC, can be downloaded from the Eclipse website.

Complaints? None really. Oh all right, here's a nitpicklette because it's you: at page 75 Mr Kiselev adopts the irritating Internet habit of writing 'loosing' when he means 'losing'. Note to publisher SAMS proofreaders: do I win 25 cents?

For the rest, this is a lucid and readable book that describes the Next Big Methodology. I'm a bit alarmed at the prospect of squeezing new actions into the cracks of existing code, but I dare say I'll grow to love it.

A word of warning to the eager: since this technology is currently implemented as a species of preprocessor that relies on having all the source code available at once, so it is rather slow and probably isn't going into production shops for a while. There again, I seem to remember the comparable Cfront C++ compiler doing rather well, before we had platform-native C++ compilers.

And to the sceptics: if you think you can ignore AOP, don't forget the fate of the A and C type inhabitants of Golgafrincham, who having sent their B type telephone sanitizers into exile were all wiped out by a germ caught from a particularly dirty telephone.

You can purchase Aspect-Oriented Programming with AspectJ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Aspect-Oriented Programming with AspectJ More

Aspect-Oriented Programming with AspectJ

Comments Filter:

  • So, what is this? (Score:2, Interesting)

    by Juiblex ( 561985 )
    What is Aspect-Oriented Programming?? I've never heard of it!

    • Re:So, what is this? (Score:3, Insightful)

      by ralico ( 446325 )
      I've never heard of it either, but I'm suspicious of things that claim to be The next big methodology.

      From what the reviewer talked about with A types, B types and C types, it sounds a whole lot like roles and the delegation design pattern.
      Agree? Disagree?
      • The "delegation pattern" may be somewhat similar, but because it's a "pattern"- a repetitive process that a programmer does again and again- it's still bad.

        There's quite a bit of repetitive code created (copied & pasted, then search & replaced) when you make a delegator. Hopefully, Aspect-Oriented would let you skip the mechanical work of writing a delegator, and just get on to using it.

        You might describe it as the programming language compiler becoming aware of a pattern, and learning to implement it when told.

      • Here is what it is: (Score:3, Informative)

        by Rimbo ( 139781 )
        I had a chance to read about AOP a few years ago, when it was first being introduced.

        Short answer: Yes, it is the Next Big Thing.

        In the same sort of way that procedures were already implemented by experienced programmers long before languages like Pascal came to be,

        In the same sort of way that experienced programmers used virtual function lookup tables and information hiding before OOP came about,

        So is AOP. It is program-language-level support for the sorts of things experienced programmers do already... namely, code generation and automatic code modification.

        Basically the reason OOP came about was that there was no means to add functionality to code without going into that code and inserting a call to the new functionality. Experienced programmers made virtual functions and lookup tables to solve this issue, but obviously this sort of code is complex and prone to error. So OOP brought forth program-language-level support for this sort of feature.

        The problem that AOP addresses is this: As powerful as OOP is, it still relies on functional decomposition. The trouble is, sometimes one thing changes that cuts across functional boundaries. For example, the performance of an application, when ported to a new system, may need an entirely different set of performance tuning for the new app. Or more likely, you simply didn't see some aspect (there's that word) of your code changing often, and it would be impossible to separate it into a module without restructuring your entire code.

        Now you can do a lot of inline #ifdef's and the like to do this by hand. Or, you can use some sort of dynamic code generation. But writing a dynamic code generator by hand is, like the virtual function table example above, tricky and always ad hoc.

        The ultimate goal behind AOP is to make code generation generalized and done at the language level. So that you can modify things that occur across the boundaries of the existing functional decomposition.

        Does that make any sense?

    • Re:So, what is this? (Score:5, Insightful)

      by Minna Kirai ( 624281 ) on Tuesday March 04, 2003 @12:47PM (#5433515)
      I've read a few papers, but never managed to pay much attention. However I tried to put it in terms of how you might accomplish such effects with a traditional programming langauge.

      Basically, imagine if you wrote a program which had "hooks" scattered through it. As you write your code, you place hooks for before/after doing many things: reading user input, transmitting network data, accessing preference files, checking permissions, etc. (Imagine wrapping all your function calls with dynamically-bound functions which you don't yet know if map to an identity function, or have some effect)

      Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).

      Now, imagine than rather than the programming having to plan ahead to scatter hooks all around his code (uglifying it towards readers who don't care about them), they are inserted automatically by the compiler.

      So a person can create a function which will be automatically called whenever some other set of 3 different functions is called, without having to go modify each one. Instead of going to each function body and adding a call, he at one position attaches his code to functions of that kind. The program is shorter, but has more effects. This may mean, when all goes well, that if someone adds a new function with similar effects, those hooks may still get called.

      Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?

      In both those cases, the program is doing things that the source code doesn't make 100% clear to a programmer reading a single function body. This can be either good or bad. The usage of editing tools which evaluate the code and alert the reader to these facts (analogous to "class browsers" in several IDEs) shift it much further towards "good".

      • Re:So, what is this? (Score:5, Interesting)

        by Caoch93 ( 611965 ) on Tuesday March 04, 2003 @01:02PM (#5433616)
        Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?

        It's my opinion that, if you have to ask that question, then you and everyone else on your team are doing AOP in a bad way. The entire function of AOP is to separate disjoint concerns so that you don't think about them when you're programming. You write application logic. Your fellow team member maintains your security aspect. You don't ask "When I call this method, will it trigger the security aspect?". Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.

        Long story short- if two separated concerns in AOP have such a sufficient dependency that you have to ask yourself a question like that, then they should not be separate concerns at all. At least, in my opinion.

        • Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).

          Which will inavoidably lead to very bad code. Remember operator overloading in C++, where a similiar overuling of semantics was possible? Because of its abusive potential it was one of features that became considered bad practice if used at all later.

          Regards,
          Marc

          • That's Sun's opinion, but disregard for operator-overloading is by no means [c-sharpcorner.com] universal [leepoint.net].

            Only dumb programmers become any more confused by operator overloading than by other kinds of overloaded functions.

            I don't want to reduce the effectiveness of the smart ones by sheparding the stupid.
      • Basically, imagine if you wrote a program which had "hooks" scattered through it.

        Imagine what would happen if one of these AOP folks would try to sell it to Dijkstra ("Go To Statement Considered Harmful", Communications of the ACM, Vol. 11 (2), pp. 147-148, 1968).

        Regards,
        Marc

        • They certainly wouldn't approve of manually adding hooks everyplace, which is what AOP tries to avoid (while still giving the programmer the power as if that had been done)

          How far would AOP meet with his approval? Good enough, it seems. Dijkstra's criteria [acm.org] for allowing a feature into a language was how much it complicated the description of the "cursor position" ("textual index point") of a program at a certain time. Gotos are bad, because they make the size required to describe that position unbounded (the full history of all previous goto jumps). Structured programming, with nested blocks and function calls, keeps the size limited, because the position-descriptor shrinks when you leave a block. (As long as there's no infinite recursion, but even that can sometimes be handled)

          AOP's effect on the execution graph is the same as function calls. It's just the calling of functions, but the calls themselves are implicit and invisible. The textual index size is only increased by a small constant factor per aspect called, and that size is recovered when it's done.

          • Re:So, what is this? (Score:3, Interesting)

            by mvw ( 2916 )
            Dijkstra's criteria for allowing a feature into a language was how much it complicated the description of the "cursor position" ("textual index point") of a program at a certain time. Gotos are bad, because they make the size required to describe that position unbounded

            Bounded and large would be worse enough. Let me rather cite:

            My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

            AOP, like operator overloading in C++, can introduce amazing surprises to a programmer. A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.

            Regards,
            Marc

            • Re:So, what is this? (Score:3, Interesting)

              by Samrobb ( 12731 )
              A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.

              That's a true statement about any program. Just try tossing in a random uninitialized pointer or runtime exception here or there in any utility function, rebuild, and see what happens.

              I've written "aspect"-like code before... a system that I worked on not too long ago (hey, Honus!) made use of a pretty nice set of functions and macros in order to:

              • trace function call entry
              • do parameter checking
              • log return values
              • log exceptions/unexpected return values

              This involved manually adding the appropriate macro at the start and end of each function. A pain in the butt, and the inevitable tyop came back to bite you hard :-/ IMHO, this is the type of problem that aspect oriented programming is intended to solve.

              Yah, improperly coding an aspect could cause all sorts of heartache and difficult to solve problems. But... when we did the same thing by hand, it still caused heartache and difficult to solve problems. I'll take AOP (supported by an AOP-aware debugger) over doing this sort of thing by hand any day of the week.

      • Re:So, what is this? (Score:3, Interesting)

        by ergo98 ( 9391 )
        While hardly the same thing, at the binary level this reminds me of Detours [microsoft.com], a very cool binary interception package from Microsoft Research [microsoft.com]: Without the sourcecode it allows you to target and intercept calls at the function level, useful, for instance, for timing the framerate of an OpenGL application for instance (I wanted to know the effects of various settings so I intercepted the flip/render command in the opengl system calls...voila I had an exact timing of every frame interval). Of course this is much less of a scope, but it is a tremendously useful little tool.

    • Re:So, what is this? (Score:3, Informative)

      by whazzy ( 620752 )
      Aspect-oriented programming (AOP) is a new language paradigm proposed for cleanly modularizing the crosscutting structure of concerns such as exception handling, synchronization, performance optimizations, and r esource sharing,that are usually difficult to express cleanly in source code using existing programming techniques. AOP can control such code tangling and make the underlying concerns more apparent, making programs easier to develop and maintain. In aspect-oriented programs, the basic program unit is an aspect. An aspect with its encapsulation of state with associated advice, introductions, and methods (operations) is a significantly different abstraction in comparison to the procedure units within procedural programs or class units within object-oriented programs. The inclusion of join points in an aspect further complicates the static and dynamic relations between aspects and classes My humble request:Please take a moment to use Google before you feel the urge to click the submit button here:-)\

    • Re:So, what is this? (Score:5, Insightful)

      by tickleboy2 ( 548566 ) on Tuesday March 04, 2003 @12:50PM (#5433532) Homepage

      Aspect Oriented programming is a brand new programming paradign, kinda of like the switch you made when going from functional programming to object oriented programming. It's a different way of expressing your programs

      The reason that Aspect Oriented Programming was created was due to "cross-cutting" concerns that cannot be easily modelled in object oriented programming. I read the presentation for AspectJ and the example they used was logging in Apache Tomcat. Bascially the code that is used for logging is scattered throughout the whole program on hundreads of different lines, not all in one nice neat class. Aspect Oriented Programming wants to give the programmer the tools to gather all of this code together.

      Bascially, Aspect Oriented Programming is supposed to result in: less tangled code (code that is fragmented throughout your program because you are unable to modularize it well), more natural code, shorter code, easier to maintain and evolve, and more reusability.

      One question I had about the book that the review didn't seem to answer was did the book talk at all about designing using Aspect Oriented Programming? Just like Object Oriented Programming, it's a great tool until you get some inexperienced programmer who just knows how to program functionally, and thus doesn't use the advantages of aspect oriented programming. I too would like to learn more about how to go about designing a program in an Aspect Oriented way; such as how to identify aspects, what are some common aspects, etc.

      In all, I'm very excited about Aspect Oriented programming. I think it has the ability to allow programming to shape thier programs more naturally, make their programs easier to understand, and make the whole process much eaiser. But of course as with any new technology, it has some growth and refinement to go through yet.

      Those of you who would like more information can check out the AspectJ [eclipse.org] webpage, or the Aspect Oriented Software Design [aosd.net] webpage.

  • I prefer reading... (Score:5, Funny)

    by borgdows ( 599861 ) on Tuesday March 04, 2003 @12:23PM (#5433311)
    Microsoft-oriented development book at Microsoft Press!

    This book contains every programming concepts and practices to avoid like hell!
    • That's truer than you think. For instance, take this "Code complete" book by some Microsoft guy. I went through the horror of being forced to read some chapters of it in college. It recommends monstrosities like "Hungarian encoding": the name of each variable should reflect 1) its data type 2) what type of variable it is ("counter", "array index", etc) 3) what its supposed to do 4) what you were thinking when you named it, and other things too numerous to list.

      This is from /usr/src/linux/Documentation/CodingStyle

      Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

      • Having types work their way into names isn't entirely brain damaged. The hungarian way may be -- I tried it for a while, and couldn't make it stick. However, some data types lend themselves to it. Ever notice how often file pointers have the name fptr? That's because the naming convention serves the programmer -- programmers have an abstract convention of a file pointer in their head, and they work with it. Similarly, every once in a while I'll find myself giving a name like "HostList" -- a list (linked list, perl list, doesn't matter) of hosts.

        And Code Complete really isn't a bad book at all. It may give you some false starts and misdirections, but it will definitely make you think about aspects of software development methodology.

  • Fascinating (Score:5, Funny)

    by Limburgher ( 523006 ) on Tuesday March 04, 2003 @12:25PM (#5433325) Homepage Journal
    I love that aspects seems to provide alternative techniques without loosing any ease-of-use, coing-wise. I was afraid that in switching to this new method I'd loose some functionality, or maybe loose some speed, but so far so good. Nothing to loose any sleep over. :)P

  • Yet another reason to switch to Lisp (Score:5, Insightful)

    by Anonymous Coward on Tuesday March 04, 2003 @12:28PM (#5433354)
    I should have stuck with Lisp all this time. When OO became hot, we could switch to OO without a preprocessor (early C++) or a whole new language (C++ or Java). (Eventually, Lisp got CLOS -- the first standard language to do OO, in fact.) If AOP gets hot, that'll just be a few more macros.

    Once you've used a language like Lisp with closures, macros (at the language level, not wimpy C macros), and code-is-data, it's hard to go back. I feel sorry for everybody who has to use Java, for whatever reason, and will have to get a new language/compiler/libraries just to take advantage of a slight change in "what's hot today".
    • I should have stuck with Lisp all this time.

      Never trust a language with more brackets than code...

      Cheers,
      Ian

      • Never trust a language with more brackets than code

        How about XML?

        Besides, every language has barackets. Just in Lisp all bracket are unified to be as (). Other languages use various forms of brackets: (), {}, [], ";", "new-line". Python use even space identation instead of brackets (the only thing I hate in Python!).

        When the code is the data, unified brackets are much better for verification purposes. That's why XML also has unified brackets (just badly designed, IMHO).

    • Re:Yet another reason to switch to Lisp (Score:4, Informative)

      by swagr ( 244747 ) on Tuesday March 04, 2003 @12:45PM (#5433485) Homepage
      Take advantage of both languages.
      Of course, as everyone knows, there are Scheme/Lisp implementetions in Java:
      http://grunge.cs.tu-berlin.de/~tolk/vmlangu ages.ht ml
      Ones that act as interpreters or compilers to Java byte code.
      Or write your own (it's not that hard) http://www.paulgraham.com/rootsoflisp.html

    • Workarounds? (Score:4, Informative)

      by mparaz ( 31980 ) on Tuesday March 04, 2003 @12:47PM (#5433504) Homepage
      How about blocks in Java [c2.com], or functors in the Jakarta Commons Sandbox [apache.org]?
    • I agree, Lisp and Scheme support every language feature you can think of. But I think Larry Wall said it best: "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in."

      That's why after almost 50 years, it still hasn't taken over the world. Moreover, while code that operates on code is extremely powerful, it can be one of the most mind-boggling features in all of CS. In a world where many developers can't understand simple recursion, it's probably just too advanced for general consumption.

      I think languages like Python and Ruby (especially use is made of their functional programming features) find the happy medium between powerful features and approachability.

      • Re:Yet another reason to switch to Lisp (Score:5, Insightful)

        by redragon ( 161901 ) <codonnell@NOSpAM.mac.com> on Tuesday March 04, 2003 @01:40PM (#5433931) Homepage
        And I think it's easier for people to write bad LISP than bad C/C++ (though I could be wrong). It seems to me that LISP suffers from "data morph" issues more than any other language.

        (5 256 "Item" "Description") represents your base data type.

        Programmer A:
        "I don't need that first number..."
        (256 "Item" "Description")

        Programmer B (who get's A's data):
        "What happened to that number?"
        (256 "Item" "Description" 5)

        Programmer C (who get's B's data):
        "Strings? We don't need no stinking strings, we can look those up in a table! I can make that table global! Sweet!"
        (256 1 20 5)

        Person hired 2 years later to fix a bug:
        "What the f*ck?!?"

        It seems to me that Scheme and Lisp over-extended themselves, and are just too powerful/flexible for their own good, and that some "rules" should be in place...

        And as the previous poster said...
        ((((()()))))
        Lisp will make you hate parenthesis.

        C
        • Same thing happens in C/C++, perhaps more frequently:

          Programmer 1:

          struct Part {
          int number;
          string name;
          string description;
          int count;
          };

          Programmer 2:

          Oh, how inefficient; let's just replace that
          with integers and put the strings into a
          "resource table" somewhere.

          typedef int Part[4];

          In fact, by using atoms rather than strings,
          the Lisp programmer can achieve the efficiency
          of C++ Program 2 while essentially preserving
          the appearance of Program 1.

          Note that the correct way of defining the
          data structure would be with DEFSTRUCT or
          as a CLOS object.

          As for the parentheses, people who sit in
          glass houses shouldn't throw stones: C/C++
          syntax has numerous flaws. Is syntax like this
          really better?

          a[((unsigned)*(short*)b)]

          What about expressions like "a = b << c + d";
          do you really know how the precedences work out?

          Lisp syntax, with the right editor, is easy
          to input and easy to read. And unlike C/C++
          syntax, it doesn't have any precedence issues
          and it is extensible.
    • Yawp.

      What I got from the review is simply further confirmation of Paul Graham's [paulgraham.com] hypothesis that more modern programming languages are asymptotically approaching the capabilities Lisp has had for decades.

      The whole "join points / pointcuts" thing seems to me like a watered-down version of Scheme's (and other Lisps) dynamic-wind and call/cc.

      (And didn't the B-type Golgafrinchans end up populating some utterly insignificant little blue-green planet orbiting a small unregarded yellow sun far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy? ;-)

  • Bad code (Score:4, Funny)

    by Anonymous Coward on Tuesday March 04, 2003 @12:29PM (#5433357)
    System.out.println(Hello, world!);

    Where are the quotes?
    I dont trust this guy if he cant write a HelloWorld app.
    • Typical "arrogent author" code where they give you example code assuming it works without bothering to actually check it. Perhaps it was just a typo on the submitter's part.

      It's why I only resort to using prewritten code when necessary because I know I'm just going to have to debug the hell out of it and effectivly end up rewritting it.

      I even had the displeasure of asking a question on a forum and being given some code that I knew wouldn't work because I even told the person why the functions he used wouldn't work before he wrote up some crappy and obviously untested code using them. It wasted my time and his time.

      I never understood why people post crap code. I'd rather be unknown than be made irrelavent and avoided by posting untested and non working code which serves only to annoy people.

      Ben
  • I went to AOSD.net and the description there is a little thin. They say that there's a good overview in a particular issue of the ACM, but last I checked, you have to pay the ACM if you want to retrieve any articles online. Does anyone have a website that gives a solid overview of what AO is? A quick googling gives me a whole bunch of specific language pages or links back to AOSD.net.

    • Re:So, what is it? (Score:3, Informative)

      by Halo1 ( 136547 )
      The original article that introduced it can be found here [nec.com] (download links for the article in several formats are at the top). Google also has a nice collection of links [google.com].
  • I'm not getting any instant gratification from the above links and blurb. Can someone explain in a few sentences what Aspect Oriented Programming is?
    • It looks like the concept is to group common methods from many different classes into a form that can be acted on uniformly. The example they gave allows for the creation of several multi-layer classes, all related and built upon each other. A "join point" is constructed as a collection of all methods that actually create new objects. The article explained that this is particularly useful for security, since while there may be many different classes that can be created, a join point can be used to allow or disallow the creation of any or all of them in a single place. The advantage is that security code does not have to be maintained in each class independantly.

  • Sounds like pre-post "exception" handling (Score:3, Insightful)

    by binaryDigit ( 557647 ) on Tuesday March 04, 2003 @12:31PM (#5433370)
    Sounds a lot like adding a pre "exception" handler in c++, mixed with somewhat normal exception handling, and doing a Microsoft and making it declarative. Sounds like an interesting feature, but without reading the book and seeing what else there is, hardly anything earth shattering. Just another way to have the compiler/dev environment formalize a programming practice.

    A methodology hasn't made really made it until somebody has published a Proper Book

    Are they kidding. Hell there probably books out here on clipping your finger nails using a new methodology. Now days having a book don't mean squat (unless you're a tree, beaver, or a bird).

  • This is not good (Score:2, Insightful)

    by DrunkBastard ( 652218 )
    Anyone else think that such concepts as this will lead to even more laziness in programming? Even more bloated and redundant code? Maybe I'm missing the whole concept, but this seems more of a "it's not working right so lets throw some sort of wrapper around it and see if that helps" attitude rather than "hrmm, perhaps I should tear apart that function, do some debugging, see if I can simplify what I'm doing, and reduce some overhead while I'm at it..."
    • "it's not working right so lets throw some sort of wrapper around it and see if that helps" attitude

      This attitude is already pretty common. "Oh, we can't understand what this library does, so we'll write a transparent wrapper which instruments all function calls, so we can gain a clear picture of what's going on"

      If AOP was used, then at least when a programmer decides he's got to throw a wrapper on something, he can do it with a few lines of code (define an aspect on the classname, using wildcards), rather than spending all day to copy & paste every single function in the class and add his 3 lines of "instrumentation".

      And then when his foolish adventure is done, and the extra code is nothing more than a drag on performance, it can be removed (or just disabled) from a single place, rather than once again scrolling through all of a class's source code to touch each and every method.

    • Re:This is not good (Score:2, Insightful)

      by daves ( 23318 )
      Anyone else think that such concepts as this will lead to even more laziness in programming?

      ... and maybe impatience and hubris [netropolis.org] too?

  • To sum up (Score:2, Insightful)

    by Joe the Lesser ( 533425 )
    Like objects, aspects may arise at any stage of the software lifecycle, including requirements specification, design, implementation, etc. Common examples of crosscutting aspects are design or architectural constraints, systemic properties or behaviors (e.g., logging and error recovery), and features.

    Okay, so there are some objects that don't act like objects, so he wants to call them aspects and give them more power and scope throughout an application.

    The main concern is while this may improve a program, I see 'aspects' being dropped in favor of meeting a deadline.
    • Shit! We forgot to put cross-cluster locking into our modify calls... on ALL 17 DA Objects!!! What are we going to do?

      (fortunately, the day was saved by an 'object that doesn't act like an object')

      Damn, performance is screwed... let's get the preprocessor to remove our logging calls! Oh, it's Java...

      (Fortunately, AOP was enforced. We can easily just remove that aspect)

  • Eclipse Project makes AspectJ more mainstream (Score:5, Informative)

    by mparaz ( 31980 ) on Tuesday March 04, 2003 @12:35PM (#5433406) Homepage

    This letter [eclipse.org] announces that AspectJ [eclipse.org] is no longer at aspectj.org as it has moved to the Eclipse project [eclipse.org].

    I think this is a very good thing since Eclipse is one of the most popular Java development tools, and is concerned with good coding practices like refactoring and coding helpers. Plugins allow people to add their own stuff. With this, people who haven't heard of AspectJ or Aspect-oriented programming would take a look.

    Interestingly, the Eclipse homepage does not explicitly mention Java. It says, "Eclipse is a kind of universal tool platform - an open extensible IDE for anything and nothing in particular." Personally, I have only used it for traditional Java. [kalixia.com]

  • My 2 bits... (Score:5, Insightful)

    by praetorian_x ( 610780 ) on Tuesday March 04, 2003 @12:38PM (#5433428)
    Aspect oriented programming is moderately useful, though, if it isn't built into the language (and, in java, it isn't) it can be cumbersome to work with.

    In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.

    By and large, the more I work in java, and the more I work in Lisp, I realize how lacking java is in dynamic behaviors. The lisp guys yawned when OO became all the rage because, well, it is so easy to do in lisp. If AOP gets big in java, they will yawn at that too:

    "Oh, so functions and try blocks are your boundry block for inserting aspect oriented code? Well, *every parenthisis* is ours. Put that in your JVM and smoke it."

    Cheers,
    prat

    • Re:My 2 bits... (Score:5, Insightful)

      by Fnkmaster ( 89084 ) on Tuesday March 04, 2003 @01:10PM (#5433664)


      In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.


      Sure, of course you can. AOP is a technique, supported by tools, it doesn't need to be hoodoo magic to be useful. Mind you, like you said, it'll get you 50% of the way. You can get 50% of the benefits of assertions by writing a static Assert class and using it consistently. It's just that it is nice to have capabilities either built into the language to support good practices, or extensions to the language (a la AspectJ) to support them.


      And the List thing is tired. We all know that Java is limited. It's limited compared to C++, it's limited compared to Lisp. Ya know what? That's a good thing. For large software development projects with many engineers involved. I can pick up other people's code and not worry about whether X really means X or whether it's a macro that's been defined elsewhere to mean Y. I realize my view on this isn't the most popular on Slashdot, but that's probably because people haven't had to manage teams of developers who aren't populated throughout with brilliant coders, capable of writing fast, functional readable code in languages that leave n degrees of freedom.


      Adding capabilities to a language to support a particular kind of new programming paradigm is not unreasonable. I realize that the fact an extension to the language is needed seems like a limitation, and it is, but like I said, that limitation can be a godsend, and it's worth the tradeoff.


      Of course, when I'm working on my own time on my own projects, I far prefer to use a manly language like C++, or a pleasant language like Python.

    • Re:My 2 bits... (Score:4, Informative)

      by ctrimble ( 525642 ) <ctrimble&thinkpig,org> on Tuesday March 04, 2003 @01:11PM (#5433670)
      Gregor Kiczales, the lead on the AspectJ project, wrote "The Art of the Metaobject Protocol" [amazon.com], which was a description of how to do metaobjects in Lisp (metaobjects, and particularly generic functions, are closely related to AOP). A description that Gabriel and Steele put together can be found in The Common Lisp Object System: An Overview [dreamsongs.com]

  • Portable.NET uses AOP for the C# compiler: treecc (Score:3, Insightful)

    by manyoso ( 260664 ) on Tuesday March 04, 2003 @12:42PM (#5433458) Homepage
    One example of Aspect Oriented Programming for compiler writers:

    http://www.southern-storm.com.au/treecc_essay.ht ml
    http://www.southern-storm.com.au/treecc.html
    ht tp://www.southern-storm.com.au/treecc_doc/treecc _1.html#SEC1

    It is also rumored that Portable.NET will use treecc for the creation of a JIT engine sometime in the future.

    From my limited understanding, Aspect Oriented Programming combines the power of the Visitor and Inheritance patterns without the drawbacks of either.

    Another interesting link:
    http://www.pcmag.com/article2/0,4149,440611 ,00.asp
  • From reading the review, I'm not sure Aspects are going to really do much for me. It seems to be "encapsulating" some code needs in an object format, and that's about it.

    I see plenty of crappy code all the time. I see lousy use of OOD/OOP. People haven't even adapted to OOD/OOP very well. I can't see this being much more than a technique curiosity that may solve some needs here and there for quite some time to come.

  • How true (Score:5, Funny)

    by arvindn ( 542080 ) on Tuesday March 04, 2003 @12:44PM (#5433479) Homepage Journal
    It doesn't matter how big and popular the website is.

    Yup. Nothing can save it from slashdot.

  • Other Aspect Oriented Technologies (Score:5, Informative)

    by Frums ( 112820 ) on Tuesday March 04, 2003 @12:45PM (#5433495) Homepage Journal

    Since AspectJ is getting some attention I figured i would point out some other AOP resources

    • MDSOC - Paper [ibm.com] - Is basically IBM's take on AOP. It avoids creating Aspect Space and Object Space (what belongs in an aspect, what in an Object?) but is less mature than AspectJ
    • HyperJ - Home [ibm.com] - IBM's Java language stuff supporting MDSOC
    • JAC - Home [aopsys.com] - Aspect oriented middleware for Java. I haven;t explored this one much, is on my todo list.
    • Aspect Browser - Home [ucsd.edu]- A tool to help identify crosscutting concerns in Java (emacs!)

  • disgusting (Score:5, Insightful)

    by rpeppe ( 198035 ) on Tuesday March 04, 2003 @12:57PM (#5433585)
    Sounds like a disgusting way of trying to legitimise hacks to me. Changing code in ways it wasn't meant to be changed, guaranteed to break lots of things (hence the "horribly easy to accidentally create infinite recursion" reference... no shit Sherlock!)

    When will people realise that the most important thing in a programming language is to make it possible to reason about one part of it independent of another part? Most of the time spent developing a program is spent modifying code, not creating new code!

    Unfortunately people don't realise this: they just want a way of hacking something existing into something different, cross their fingers and hope that it works when someone changes some other part of the system.

    Sadly, it's not just AOP: some of the "usual" OO programming language features suffer this kind of problem too [micro-workflow.com].

    Then again, maybe I'm completely wrong, and AOP has a sound theoretical basis and has been created by someone with deep understanding of programming language developments over the last thirty years... someone please reassure me!

    • Re:disgusting (Score:3, Insightful)

      by agedman ( 452916 )
      I've used AspectJ a fair amount. I'm not sure if it is the next hot thing, but it is more interesting than rpeppe gives it credit for being.

      When will people realise that the most important thing in a programming language is to make it possible to reason about one part of it independent of another part?

      Actually, this is precisely what AOP seeks to do. By gather all the logging or DB transaction logic into one place and giving rules to the compiler for determining when/where to insert that code, you achieve a very clean separation of concerns.

      The business logic writer doesn't have to know about logging or transations, trusting that the aspect writer it correctly specified. However, if the business logic writer comes upon a special case, that could be handled outside the general Aspect covering that.

      ...hence the "horribly easy to accidentally create infinite recursion" reference...

      Attempting to apply Aspects to Aspects can get a bit dangerous. But then so can recursion, reflection or any other powerful tool.

      I think AspectJ is an interesting technology that you ought to check out before sneering at. Certainly it does have problems - my biggest problems with AspectJ spring from it not being tightly integrated with the language. When I used it, there were issues with debugging, building large projects and with non-hacker acceptance. With any luck, these have been dealt with.

  • AOP Resources (Score:4, Informative)

    by Vagary ( 21383 ) <jawarren@gmail.cAUDENom minus poet> on Tuesday March 04, 2003 @01:00PM (#5433604) Journal

    The Software Practices Lab [cs.ubc.ca] at UBC has been doing all sorts of AOP research lately. Of particular interest:

    • A study [cs.ubc.ca] to determine whether AOP is actually useful.
    • Implementation [cs.ubc.ca] of all the GoF Design Patterns in both vanilla Java and AspectJ.

    They're also working on AspectC and AspectSmalltalk. It's my understanding that UBC is one of the major world centers in AOP research -- do you think I should do a PhD there?

  • My take on AOP... (Score:5, Insightful)

    by Fnkmaster ( 89084 ) on Tuesday March 04, 2003 @01:01PM (#5433612)
    I checked this out almost a year ago now, and I'm sure it's come a way since then. First off, AOP is not going to replace OOP or any other paradigm of programming. It simply provides a viable alternative way to think about the control flow and execution of a program, and a shortcut for making more maintainable code.


    Anybody who has worked extensively in Java has found this problem before. Cross-cutting concerns - you know, those systemic things that infiltrate their way into every module of your humongo-system, no matter how you try to partition it. Now, object-oriented programming, isn't that supposed to let you "blackbox" things so you can just abstract away such things and throw them in some "common" or "system" package and be done with it? Sure, you can. And you probably have. And I've done it too.


    But these solutions can be suboptimal - for example, a project I once worked on had an Interface in the com.blah.blah.system package for logging, messaging, persistence, and some other features. These were always nasty pains in the ass to manage. I mean, some implementor of these objects existed everywhere in the system - if something changed fundamentally, or there was some insuffiency in the interface that was discovered, god forbid, you'd have to root around for hours changing code everywhere. Especially when exception signatures changed. Which eventually leads, in sheer frustration, to using Runtime exceptions everywhere, or declaring all of your "system" interfaces with "throws Exception". Ugh. Each solution seems worse than the problem.


    Admittedly, problems like this can be solved with good refactoring tools and practices. But not always well. The exception issue for "system" or "cross-cutting" interfaces was one I've never seen solved well (again, I'm thinking of Java here, it's the language I have the most experience working in large commercial-scale projects in where this stuff is really important). If you are working on medium or small sized open source projects, or medium or small sized tools or desktop applications, you may never have come across these kinds of limitations or frustrations in sufficient numbers to justify looking into AspectJ/AOSD in general. But if you've worked on large enterprise software projects, I'm sure you can see that there is a need to "patch," but certainly not replace, the standard OOP methodology to address these kinds of concerns.

  • Hasn't CLOS had this sort of thing (15 years ago) (Score:3, Interesting)

    by helixcode123 ( 514493 ) on Tuesday March 04, 2003 @01:04PM (#5433632) Homepage Journal
    This sounds similar to the Common Lisp Object System (CLOS) :before and :after methods.
    If I remember correctly, in CLOS you can specify a method "foo", and then another method "foo" with the ":before" modifier that would be executed before the normal "foo" method. There is also an ":after" specifier.
    • Yes, and languages like SmallTalk and Ruby also allow similar constructs.....the one advantage I can see from looking at the AO extensions to Java is perhaps a little more clarity in being able to quickly see the melds between methods of disparate classes, but the functionality is no different.

      I did see a project on sourceforge to add explicit AOP to Ruby, perhapss making code more understandable, but of course one can hook methods without it
    • If I remember correctly, in CLOS you can specify a method "foo", and then another method "foo" with the ":before" modifier that would be executed before the normal "foo" method. There is also an ":after" specifier.

      Yes, and relational databases have had trigger methods before and after different SQL operations. You can define 12 triggers on a table in Oracle, made out of combinations of (before, after) (insert, update, delete) (for each row, for each statement). You code them in PL/SQL which is a fairly comprehensive language similar to Ada. Is AOP merely triggers for Java methods? Because you could do that already, by subclassing, overriding the method, and calling the superclass method within your own code.
  • I don't mean to disparage AOP or anything, but getting it right in practice is often a far cry from applying methodologies. I've sat through a software engg course, and its irrelevance to writing good software is striking.

    Go read The art of UNIX programming [catb.org] (online) NOW!. The author is ESR. Its an amazingly useful book. It cuts out all the hype and gives you a higher-level philosphical insight into effective programming.

    Quote from the book:

    Assemblers, compilers, flowcharting, procedural programming, structured programming, "artificial intelligence", fourth-generation languages, object orientation, and software-development methodologies without number have been touted and sold as a cure for this problem. All have failed, if only because they 'succeeded' by escalating the normal level of program complexity to the point where (once again) human brains could barely cope. As Fred Brooks famously observed [Brooks], there is no silver bullet.

  • Overlooked extensions to C (Score:5, Funny)

    by WebfishUK ( 249858 ) on Tuesday March 04, 2003 @01:07PM (#5433648)


    Instead of looking for radically new approaches in computer language development why doesn't someone introduce more colour into standard C. For instance we have if and while, how about adding verbs such as when, where or how.

    Taking it further we might like to introduce more polite language into code such WouldYouBeSoKindAsTo or WhenYouAreReady. Imagine the code you could write...

    when (time == "morning")
    WouldYouBeSoKindAsTo (turn_on_alarm);

    Alternatively we could convert C from English into, say, German. So if would become wenn etc. You could even mix nationalities. For instance if you wanted to be very forceful about a particular if statement you could use the German. If you wanted to seduce the code you might use the French.

    Come on all it takes is some imagination. (Alternatively we could all just start using befunge [catseye.mb.ca]!)

  • AspectJ is a safe warm power drill (Score:3, Informative)

    by Anonymous Coward on Tuesday March 04, 2003 @01:08PM (#5433655)
    I'd have to disagree that it won't be used in production shops any time soon. It's really a matter of the word getting out, which undoubtedly will be helped by both the book and the appearance of this review on /.

    A team I was on early last year had a legacy Java db access module that was rife with poor exception handling. We wrote a single aspect that joined on all exceptions, trapping only JDBC exceptions, and had the aspect trap the SQL error code, the ISAM error code, the offending method and source code line. After recompiling the module with the aspect included, we popped the new JAR into production and used the trace files to find the offending code. Altogether it took 2 days to address the errors. So we re-recompiled the JAR, this time with the aspect removed, into production it went, and received a few beers for our "inventiveness."

    Honestly, this is one of the most useful Java tools I've ever run across. I guess I should have sent the PARC guys money for some tallboys.

  • Verity Stob (Score:3, Informative)

    by Dylan2000 ( 592069 ) on Tuesday March 04, 2003 @01:15PM (#5433703) Homepage
    is not really a real person but is one of the funniest tech writers out there. She is famous for the history of the microcomputer [ddj.com], and is widely and deeply revered by everybody who's read her

    She also did a parody of our own Slashdot [ddj.com], which is absolutely f*cking hilarious.

    I strongly recommend anyone who hasn't read any stob to go and check out the archives [ddj.com] and then laugh yourself stupid for half an hour.

    • Re:Verity Stob (Score:3, Interesting)

      by a2800276 ( 50374 )
      Yep, can't believe nobody picked up on that. While Dr. Dobbs has a fair amount of weird ecclectic columns (Swaine, Campervan-jazz-musician-what's-his-name, etc.) Verity Stob is by far the best of them. One of my favourites is the lifecyle of the desktop PC: State of Decay [ddj.com] (It's so true.)

      Nicely written, informative book review, too, by the way. Hope we see more of her here!

      Speaking of weird things to like about Dr. Dobbs, does anyone else look forward to the PC-Lint advert/riddles every month? -- Asking that feels strangely embarassing, similar to asking "Does anyone else ever find that they've been talking to themselves for the last hour with the office door open?" :-)

  • Maybe it's just me (Score:4, Insightful)

    by kfg ( 145172 ) on Tuesday March 04, 2003 @01:20PM (#5433762)
    But. . .

    This has the feel to it that the programing methodology is becoming religious dogma, rather than a useful tool.

    I've been getting that feel for a while now, as OOP languages start to compete on their "purity" or whether they're "real" OOP languages or not.

    I've been programing "Object Oriented" since the 70's. In languages, like APL, that no one would consider "Object Oriented." Object Orientation is an abstract concept in itself that allows us to more easily abstract real world items into virtual objects and to manipulate them in a virtual world.

    That's all. It is occasionally a very useful tool to have in one's bag of tricks. Sometimes it really doesn't apply at all and trying to force a fit just makes things labored and crude.

    Trying to turn the entire universe of thought and logic into formal objects ( such as the number 1, which is most definately *not* an object), is putting the dogma before the cart, which then drags the poor cart anywhere the dogma wants it to go.

    "Aspect" Orientation simply feels like a sect trying to break off from the Mother Church to me. This is not to say it may not be very useful, but that usefulness is needed because of doctrine in the first place.

    Some things are objects. Some things are just operations or functions that have to be tortured beyond recognition if they're to be objectified. The less "pure" an OOP language the more *useful* I tend to find it, because it allows me to choose my methodology based on the problem.

    Aren't there easier ways to add one and one and get two?

    KFG

    • In Ruby:
      1.times { puts "Hello World!" }

      Now there are other ways of doing that that are almost as readable and almost as useful but isn't that neat? What makes treating everything as an object even more useful is that you can treat everything the same way. You can always say obj.inspect and get something useful out of it. This is great when you're debugging something and wonder: "What the heck is this function returning?", whether it's an integer, a hash or a complex object, object.inspect will always work.

      Java makes things confusing by having both primitive types (int) and object types (Integer), because in some situations you want to be dealing with an object, but the language isn't flexible enough to let you treat the object form of an Integer the same way you would a primitive int.

      What I think makes Ruby so cool is that essentially everything in Ruby is, or can be an object, but it doesn't get in the way.

      I agree that languages that are inflexible can be rough because they limit your options, but how is treating everything like an object inflexible?

  • Books (Score:4, Interesting)

    by alext ( 29323 ) on Tuesday March 04, 2003 @01:30PM (#5433845)
    A methodology hasn't made really made it until somebody has published a Proper Book.

    What, like The Art of the Meta-Object Protocol [mit.edu] by the very same Gregor Kiczales et al, pub. MIT Press, 1991?

    Like most things, AOP is only new if you don't know LISP. :-)
  • For a change - it's almost like you're a real writer. This review wouldn't even look out of place on a real site.

  • Hidden Horror Show (Score:4, Insightful)

    by piobair ( 586119 ) on Tuesday March 04, 2003 @01:35PM (#5433882)
    I took a look at AspectJ awhile ago and instantly spotted the hidden horror show for implementation: There is no test you can write to assure your aspect was applied appropriately. (at least there wasn't when I looked). Apparently nobody sees this as an issue? The application of aspects is essentially a blind process before compilation occurs. The best you can do is place errors in your aspect and break the compile. I can't imagine turning this tool loose on a development organization.

  • AOP is useful, but not well suited to Java (Score:3, Interesting)

    by kahei ( 466208 ) on Tuesday March 04, 2003 @01:35PM (#5433887) Homepage

    I think the reason there are so many 'huh? why do I want to do all this?' responses is that Java is not a language that lends itself to AOP, and that AspectJ therefore has to build this scary layer of 'pointcuts' and so on on top of it.

    With a language that lets you assembly types dynamically, like Ruby or Perl, AOP is much simpler and more natural, so it's easier to get a feel for the benefits.

    In particular I think Ruby is well-suited, although you do lose some type safety. There is a package called AspectR available, although you *could* do it all youself with mixins and the like.

  • A dinosaur writes: (Score:4, Insightful)

    by Chocolate Teapot ( 639869 ) on Tuesday March 04, 2003 @01:46PM (#5433976) Homepage Journal
    OK, I confess. I didn't even bother to read the article, and will probably be ridiculed for not being up-to-date with hot new technologies (AKA 'fads'). I just skimmed through Verity Stobs' story and groaned. It seems that every few months there emerges a new programming language/methodology. Maybe, instead of devoting so much time to inventing new tools, people should invest their energy into learning to use the existing stuff properly. I wonder how many peoples resumés are littered with long-dead languages that 'seemed cool at the time'.

    P.S. I don't dress fashionably either, prefering to save valuable beer money.

  • I bought it - its worthless! (Score:4, Interesting)

    by NovaX ( 37364 ) on Tuesday March 04, 2003 @01:50PM (#5434005)
    I bought it back in january, after first learning about AOP. At the time, it was the only book I could find directly on AOP, with a second coming in feb. Otherwise, the only other text source I could find was Generitive Programming.

    So I bought it, and I was excited when I began reading. Then I found out it was just a bunch of JSP and other then the first 25 pages, very little content. Now I admit I put it down a good 25 or so pages later and skimmed through the rest, but I was extremely disapointed in it. Instead I've been grabbing all of the ECOOP workshop documentation.

    In the end, it was worth the money. No, not for the book, god no! But by getting me excited and reading the ACM Communication articles and then talking to my adviser about it. It turns out the editor for the AOP material in the ACM communications is a professor at my school, and even better is happy to let me help her out next semester (I'm extremely swamped now). So now I'm considering doing the thesis option on my masters. I'll spend the summer reading REAL material.

    My opinion: AOP is awesome but the book is a waste of money. Here are a few good readings:

    Alternatives to AOP [lancs.ac.uk]
    Generitive Programming chapter [tu-ilmenau.de]
    AOP publication [parc.com]
    AOD 2002 workshop [iit.edu]
    ECOOP97 [uni-trier.de]

  • Some thoughts from somebody who's using the tech (Score:3, Insightful)

    by Anonymous Coward on Tuesday March 04, 2003 @02:07PM (#5434140)
    1. Yes, it's powerful. Very, very powerful. Using Aspects, you can now centralize code that you would have had to manually put at the beginning and/or end of each method in class X, or each method Y in class X, or each method Y in classes X and Z, or whatever. Used properly, damn straight this makes your code more maintainable. However . . .
    2. The abuse potential is breathtaking. Most conspicuously, it introduces a ton of ambiguity to what's getting executed when. When tracing code execution, it's no longer adequate to simply follow what methods get called when; you now have to check to see if any of your Aspect classes are poking their fingers in anywhere. Which is a problem because . . .
    3. Figuring out what Aspects get executed when is not a trivial concern. You can definitely wind up with Aspects executing in places you don't expect, or ignoring places you think they should hit, just because there's some element to their behavior you don't quite understand perfectly.

    In short, used judiciously, this is a very, very handy tool. Used indiscriminately, this is an utter fscking nightmare. And anybody who lets the project's junior-level coders work with this should be taken out back and shot. Repeatedly.

  • I hate aspect oriented programming... (Score:4, Funny)

    by Mysticalfruit ( 533341 ) on Tuesday March 04, 2003 @02:33PM (#5434450) Homepage Journal
    I work my ass off and write a program and when I send it to my boss he's always sitting infront of his monitor at a different angle and it looks and works totally different.

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close