Slashdot Mirror
Aspect-Oriented Programming with AspectJ
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.
What is Aspect-Oriented Programming?? I've never heard of it!
I honestly don't understand the applications for this. Maybe it's just because I'm reading the review rather than the actual book, but it does'nt feel all that useful.
I can understand the benefits of OOP over standard top-down programming, but I'm failing to see where this coding methology gives you any gains.
I'm a lawyer, but not yours. I wouldn't represent someone who thinks taking legal advice from Slashdot is a good idea.
Microsoft-oriented development book at Microsoft Press!
This book contains every programming concepts and practices to avoid like hell!
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
You are not the customer.
And you might look less like a total dickhead.
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".
System.out.println(Hello, world!);
Where are the quotes?
I dont trust this guy if he cant write a HelloWorld app.
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.
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?
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).
Another obscure and pointless programming paradigm dreamed up by an academic who
wants to make a name for himself. God save us from the egos in the computer world...
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
One example of Aspect Oriented Programming for compiler writers:
t ml t tp://www.southern-storm.com.au/treecc_doc/treecc _1.html#SEC1
1 ,00.asp
http://www.southern-storm.com.au/treecc_essay.h
http://www.southern-storm.com.au/treecc.html
h
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,44061
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.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Yup. Nothing can save it from slashdot.
What do you mean there is no such setting?
Since AspectJ is getting some attention I figured i would point out some other AOP resources
How about blocks in Java, or functors in the Jakarta Commons Sandbox?
I urge you all as fellow members to avoid purchasing this book. Save your time and money, as they're both valuable things that this "amazing" new theory that promises to change the world will waste. The creators want us to believe that Aspect will make some programming utopia, but you know what? Hitler said the same thing about his "great new idea" and look where it got him.
Object-oriented is a common sense, practical way to view the world. You treat the variables in your program as objects, and you think about how a real-world object and what its private values would be and what operations you would be able to perform on it. It's a very pragmatic approach.
I've read this Aspect book, though, and it sucks. There's nothing new or innovative, as I'm sure you can see from the Hello World example. Does it look like any ordinary Java or C# code? Yup.
So please, save yourself thirty dollars and a heck of a lot of time and don't ever touch this book. Spend time improving the code you've already written rather than wasting time on theoretical gibberish that won't result in any improved programs.
What we really need is better error prevention, not some new style to program in. Get your priorities straight.
31 people regularly point & click my G-spot
If your OO program is large enough, you naturally begin designing things "aspect oriented" without even knowing that it is called so. If someone needs to explain this to you, you should not be in programming.
That is rather limited undestanding. Bog-standard CLOS does that. AOP is like a comprehensive set of :around-method-like extensions to CLOS via the MOP.
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.
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!
People are going crazy over COMEFROM.
The Software Practices Lab at UBC has been doing all sorts of AOP research lately. Of particular interest:
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?
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.
tone
tone
Yes Microsoft Corp makes very buggy software. It is true.
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.
In a band? Use WheresTheGig for free.
Logging is an easy one for AOP. Here are some more interesting things you can do:
1. Security processing...weave security checks into your code.
2. Transaction monitoring.
3. Automatic event propagation (get rid of those nasty JavaBeans listeners).
If, in a given situation, you call several methods in order, and that pattern is repeated across many other methods, each of those calls is a candidate for AOP, where you weave the calls in directly through pattern matching, rather than typing.
It can result in dramatically reduced code. It also _enforces_ behaviors (like when you forget to add that one line that does the security check).
Without AOP you are programming by exceptions, not by rule.
treecc was specifically designed to aid in compiler design and it turns out that this is one of the examples that make for a good AOP solution. This is the relevant blurb from Rhys's article on treecc:
Go read The art of UNIX programming (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.
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!)
-- "Can't sleep, clowns will eat me!"
The software development industry has seen so many different approaches to designing the design process in the past three years that the pointy haired bosses of the world are now running around in circles. This is a good thing. Now that the ivory tower managers are busy contemplating their navels, the people who actually roll up their sleeves and write something can actually get some work done - my point being that the time spent in such pursuits rather than doing the basic project planning that any software development manager with half a brain knows how to do in his sleep merely slows down the project and confuses the hell out of the programmers.
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.
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, and is widely and deeply revered by everybody who's read her
She also did a parody of our own Slashdot, which is absolutely f*cking hilarious.
I strongly recommend anyone who hasn't read any stob to go and check out the archives and then laugh yourself stupid for half an hour.
Build your own website - full service homepage system your m
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.
Not this Joe! OO is full of bullshit and unsubstantiated claims. oop.ismad.com
Before you mod me down, link me some evidence that OO is better for custom biz apps besides brochure-talk and anecdotes. I can guarentee you have no such thing. It does not exist.
Table-ized A.I.
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
Time to get new glasses. ;)
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
It's 'odor', not 'odour'. Stop corrupting the fine American language.
A methodology hasn't made really made it until somebody has published a Proper Book.
:-)
What, like The Art of the Meta-Object Protocol 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.
If you can't see this, click here to enable sigs.
In this sense aspect programming is only a small step in the right direction, which is Generative Programming.
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.
I have a second sig, I call it sig#2.
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.
Whence? Hence. Whither? Thither.
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."
And he thinks Perl is an improvement?
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.
:)
Aspect-oriented programming is a castrated version of a moderately old reflective programming paradigm: Metaobject Protocols. I won't go into lengthy explanations of that; it is suffice to mention though that Kizales, the father of AOP, is coincidentially published a book called "The Art of Meta-Object Protocol" in early nineties, and that, say, Lisp programmers use MOP for about decade now. So AOP is just yet another toy replica for people in the sandbox
Lisp is the Tengwar of programming languages.
Keep trying... you will succeed soon.
Oh, and VEGANS SUCK. Seriously. No joke. They SUCK complelely.
P.S. I don't dress fashionably either, prefering to save valuable beer money.
Modest doubt is called the beacon of the wise. - William Shakespeare
Your opinion is baseless and stupid because I am right and if you disagree with me it is because you know nothing and are an idiot.
paraphrased from the average slashdot post
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
Generitive Programming chapter
AOP publication
AOD 2002 workshop
ECOOP97
"Open Source?" - Press any key to continue
Your opinion is baseless and stupid because I am right and if you disagree with me it is because you know nothing and are an idiot.
paraphrased from the average slashdot post
I think you are wrong. You have no foundation for any of the above claims. You should agree with me now or you are insane. Clinically.
I had never heard of AOP before this article, but it does sound familiar. This is one of the ways existing (elisp) code in emacs can be modified (see elisp docs). I have found it to be a very nice way to quickly make small modifications to large pieces of existing code.
And you don't bring your standard libarary, okay?
Hundreds and hundreds of people are reading this right now... how can you waste their time like this with a clear consience?
All I have to say is that your opinion is baseless and stupid because I am right and if you disagree with me it is because you know nothing and are an idiot.
Lets not turn this into an anti-newbie IRC channel where "RTFM" is spouted in response to any question you don't like. If you didn't want to answer the guy you didn't have to post anything in response but telling him to google something before they post to Slashdot is a bit much.
Mac OS X and Windows XP working side by side to fight back the night.
Break the cycle, don't reply!!!
Your opinion is baseless and stupid because I am right and if you disagree with me it is because you know nothing and are an idiot.
paraphrased from the average slashdot post
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.
In soviet russia, the cycle breaks you...
Ironically, that is a truthtitude.
You breaks cycle the, russia soviet in.
Truthtitude a is that, ironically.
Hot petrified beowulf cluster natalie "grits" portman ???? profit.
Modularity, encapsulation, separation of concerns or whatever you want to call it is still a good idea.
Aspect Oriented Programming claims to support a new kind of modularity, but what it really does is break encapsulation.
Imagine you're responsible for a module in a big system. Over the years, well meaning aspect oriented programmers stick more and more little hooks into your code. Eventually like Gulliver, when you try to move, e.g. fix or improve your code, you simply can't without breaking the hooks that tie you down.
If they had used your published interface and you designed a good interface, you would have been ok, but no! They reached into your code and created dependences on your implementation. If it's production code and you break someone else's code, you'll be seen as the bad guy.
Many years ago I used Xerox Lisp machines and worked near the inventors of Aspect Oriented Programming. I used two precursors of AOP. I used the advice mechanism in InterlispD and later Active Values in it's object oriented extension Loops.
When used very sparingly, advice was useful, especially for debugging and working around bugs. The advise function allowed you to add wrappers to functions that would replace, preceed or follow the invocation of the function. You could further restrict the advice to apply only when a function was called from within another function.
Active Values, on the other hand, were an advice mechanism applied to object field access. People quickly realized that the facility was a mess because there was rarely any hope that you could get your advice to run *only* when you wanted it to and rarely any hope that you could avoid a unreadable tangled mess. There were new getter and setter functions that didn't trigger the active values, but this just added even more complexity.
It would be much easier to design an explict hooks than to worry about what happens if someone sticks an active value in any and every object field. Especially when the field may already have an active value.
It's vital to be able to assume that when you read a line of code, you know what it means and if not, you know where to look up what it means. Rather than enabling hacks like aspect oriented programming, we need better tools for making clean changes that sweep across the source code and thereby do away with the urge for this perilous patching stratgy.
I never realized this sleaze had this power! :o
is it warm down there in your little shell?
Yes, I got the classical allusion at the beginning.
Will you marry me?
I found more information on AOP here.
"Aspect-oriented software development is a new technology for separation of concerns (SOC) in software development. The techniques of AOSD make it possible to modularize crosscutting aspects of a system.
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.
Researchers in AOSD are largely driven by the fundamental goal of better separation of concerns. So while crosscutting tends to be a significant focus of their work, they also incorporate other kinds of SOC techniques, including such well established approaches as OO and good old-fashioned structured programming. This is reflected in the way much of the work in the field blends support for many different kinds of modularity including block structure, object structure, inheritance as well as crosscutting."
AOP seems likes yet another over-hyped way of programming. I read about AOP and nothing jumps out at me why I really need to use this in my work. The average "Joe Coder" does not care for this crap; he has to get real work done.
Just out of curiosity...isn't this a "Good Thing"(tm)?
I mean, where I work, we've got 25+ year-old legacy code that is at the heart of our stuff, and it gets built on each year. Because of expanding features, new products, etc., we rely on the fact that we also have legacy programmers here that understand it.
If we had the time and money to re-architect/re-design/re-code each release, we'd be in hog heaven when it comes to having a great opportunity to "design things well in the first place", because we could. But something designed well in the first place can't POSSIBLY make up for future enhancements and even really core code changes, because if you had the time to do such a good job in the first place, you usually lost money and went out of business. The attitude (and I don't support this, but it seems true) is "Make it work now, make it work better later" so that money can be made. Then, later really never rolls around, and it's ALWAYS there looming in the distance.
So, this seems like a great idea, to me.
Any sufficiently well-organized Government is indistinguishable from bullshit.
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.
Yes Francis, the world has gone crazy.
Aspect-oriented programming has been talked about for a while now, but it still isn't nearly ready for prime time. The obvious issues are that it will introduce bugs and that it will be at the same time very hard to debug.
The first goes without saying: every new technique can be considered a collection of novel ways that things can go wrong. Insofar as AOP is powerful, it will create whole new classes of bugs.
Things like AspectJ make things worse, though, because they are pre-processors. So debugging is going to involve tracing into machine-generated code. This does not need to be a nightmare, but somehow it almost always is.
There is also the issue of debugging your aspect specifications themselves, alluded to briefly in the article with the point about infinite recursion. I'm sure there are many other subtle and interesting bugs that AOP can introduce, and I'm very grateful to all the eager souls who are going to find and fix them over the next few years.
I think AOP solves a legitimate problem. I'm not by any means sure it's the best solution. In a few more years, when tools and techinques have matured a little, it may prove to be a valuable technique.
--Tom
Blasphemy is a human right. Blasphemophobia kills.
Doh.
For those of you who are C++ programers and would like to see Aspects in C++ check out:
aspectc.org
They are at revision 0.6 but they do provide many of the useful features in AOP. My one beef is that they don't provide the ability to specify aspects based on the 'const-ness' of a function, but hey its only 0.6 and they have a way to go before 1.0
Now that you're asking, no, there isn't.
this post was brought to you by Andreas Fuchs.
echo [Address] | sed s/[-a-z]//g | tr A-Z a-z
Object oriented code can be hard to follow for similar reasons. Operator overloading and implicit constructor calls combined with user defined types can make it tough to know what objects are invoked and where.
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?
you would have to write your code like so :
...
when (!strcmp(time, "morning"))
and what language are you coming from when you uppercase everything in WouldYouBeSoKindAsTo()? It should be would_you_be_so_kind_as_to() or simply:
void please(void * callback) { *(callback)(); }
There are also a few overlooked optimization macros that could be used in C.
// saves memory // saves cpu time
Just slip these into your header file and smoke it....
#define struct union
#define while if
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
Aspects sound like they are similar to Attributes in C#
http://www.askthevoid.com
Uh oh! A Fortran programmer with mod points. That's a dangereous combination!
Modest doubt is called the beacon of the wise. - William Shakespeare
Intercal, an old joke language, did Dijkstra one better with its innovative "comefrom" statement.
AOP is to "comefrom" as function calls are to gotos - it's certainly an improvement. But...
I think the point is that, after looking at large chunks of lisp code, even perl is an improvement.
Just think about support for tracing the execution of your program. Many applications support multiple levels of verbosity, and perhaps logging facilities. But this is largely orthogonal to the overt functionality of the system. If you tried to encapsulate tracing, you'd end up having to compromise the overall modularity.
What OO calls are to regular function calls, aspect hooks are to the infamous "come from" statement.
Wow. I can see how this could make incredibly nasty code. On the other hand, it does model what a lot of programming is all about: adding more hooks to existing systems.
LISP programs are practically always unreadable. If it's unreadable, it's unmaintainable. Look at how all algorithms are laid out in CS books: that's structured programming. They certainly don't do a step, and then have you turn to another page to do the next step, and turn to another page to do the next step.
(tail (make (get (blah (foo()), bar())))))
In the end, this lang vs. that lang is "fundamentally superior" is all bullshit since practically all languages are Turing equivalent, so practical acceptance comes down to ease of learning, readability, API and platform support, speed, and sensible amounts of syntactic sugar.
Java does all those things pretty well. LISP had 50 years to gain acceptance, and it hasn't. It has had numerous evangelizers, even whole tech startups, and all for naught.
Hey, I'm just your average shit and piss factory.
from what I have read about it and how it works, I think think the indirection it adds may create some bugs which are very difficult to track down.
I suppose I agree with one of the main axioms, which states it is inevitable that a properly deisgned OO program will have some methods which are scattered throughout many classes. What I have not been convinced of, is that good design is not sufficent to minimize these to a level at which they are more easily managed by "cross-cutting" than good refatoring tools and practices.
Anyone have 2 cents?
Scott
Modest doubt is called the beacon of the wise. - William Shakespeare
(5 256 "Item" "Description") represents your base data type.
Hmm, the Java version of this would be:
x = new Object[] {
new Integer(5),
new Integer(256),
"Item",
"Description"
};
Does anybody actually write code like this?
Sure, if you ignore all the features of Lisp, it's not going to be pretty, or easy to maintain. Replace "Lisp" with the name of any other language in that sentence and it's be equally true.
Your "data morph issues" sound like "what happens if you don't use structs". If you don't use structs in C/C++, your code will be just as bad. Lisp has weaknesses, but this is not one of them.
Go learn about defstruct. Then you'll be writing Lisp code that's at least as powerful as C.
This is a difference that can only be determined by going in and looking at the code that *actually controls your application*. Wherever it may reside.
Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.
Does this also imply that in certain situations it is not possible to have reliable behaviour?
I guess I'm just a cynic when it comes to *good* practices...
"Evil will always triumph because good is dumb."
-Lord Dark Helmet.
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 suppose this is in contrast to an AOP or OOP programmer who can't write procedural code to save their lives? (And hence write applications with unpredictable behavior and terrible performance)
Every programmer needs a certain level of knowledge and expertise. Some do a better job than others at making sure they aquire this before "doing something stupid". Just as some working environments are more conducive than others to being able to avoid "doing something stupid". It's the lack of documentation and proper training as often as individual programmers that are at fault in these situations. All programmers in critical roles need to realize their training and leadership responsibilities as well as their technical ones...
It would sure be nice if the bigotry could be left out of these discussions. Becoming an excellent functional, AOP, or OOP programmer even in lack of other skills is a non-trivial task. Excellence in any area is valuable, just as a strong foundation in all areas is important.
first step toward enlightenment is to admit YOU FAIL IT, asshopper.
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?
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
It's the COME FROM statement! Intercal has had this for years!
In the case of AOP, the "control" of the application is distributed among several different concerns. When a pointcut is reached, many different "interceptors" or "advisors" get a shot at the context of this pointcut and may perform various operations on it. Depending on how AOP is implemented in this case, the advisors may or may not be able to actually alter the data flowing in and out of the pointcut. It's relative to the way your AOP is being done. In the case of AspectJ, if you want to know how your code behaves, you read your source code. In a more dynamic environment...say...the Interceptor stack in JBoss, you look in a config file and find out what's wrapping your application logic. If you're so inclined, you can then look up the source code of your interceptors. To be completely honest, you have about as much ability to know what's going on as you do anywhere else- things are just organized differently.
Does this also imply that in certain situations it is not possible to have reliable behaviour?
Sure. Here's one situation- a member on your team writes an interceptor that intercepts some other method call and scrambles the data entering the pointcut, then applies this interceptor to points of execution in the program. Even then, though, the behavior is reliable. Why? Because it's doing exactly what it's supposed to do- it's applying someone's destructive interceptor before executing a bit of code. In my opinion, someone who would actually do this to a project is also the same someone who probably would undocumentedly scramble a struct passed by pointer into a function or overload operators so that his code could look more like a game of Yahtzee.
I guess I'm just a cynic when it comes to *good* practices...
To me, it's not a simple matter of good practice. Your basic business/application logic developer isn't going to be writing and applying aspects. Instead, s/he just writes application logic, and your security expert writes a security subsystem, then applies it over the top of everyone's business logic.
This isn't some everyday programming trick. It's designed for managing complexity and separation of concerns in large projects. To use the example of JBoss again, which is on a big AOP kick, the point is that an EJB developer just writes and EJB...the JBoss server then applies interceptors over it so that it has transaction support, caching, can be replicated across nodes of a cluster, etc.
So, your average programmer isn't going to just pointcut everyone else willy-nilly. In fact, your average programmer is never even supposed to know s/he's being pointcut.
I find this is just a programming paradigm not dependent on any programming language. As you can do object oriented programming in C, you can do aspect oriented one in languages other than Java or C++. An excellent example of this implemented in PHP is Squirrelmail plugin architecture. It provides so many hooks for plugin developers that you can do amazing things with mail headers, body, addressbooks etc.
The unclarity of code will always remain a problem for maintainers, as suggested by Minna Kirai.
The text you quoted is a good example of why OO is an inconvenient development method for compilers and similar tools.
Anyone writing a compiler for anything should have experience with implementing one using an ML-like language. People insisting on OO for everything, using Java or C# and quoting "design patterns" are not likely to have that kind of experience.
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.
1. A log message is printed when the function is entered, and when it exits (whether normally or by exception).
2. The function name is printed before each debug line.
3. The compiler should optimize out the "log" variable if debugging is turned off, but leave the "side effects" (e.g., "++i" in the above example).
You can enhance the logger class to indent when entering a function and outdent when leaving it, thus showing the level of the call stack (among the traced functions).
(Note: I typed this in off the top of my head, so there may be typos of which I am unaware.
Also, slashdot is not indenting the "//..." lines for some reason.)
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
AOP is user-defined method combination - a bit like ":before" and ":after" and ":around" in CLOS, but user-defined (like CLOS with MOP).
:-)
Really it's a buzzword used by Kizcales (sp?)to introduce a significant fraction of the potential power of Lisp CLOS and MOP (which he also designed) to the minds of programmers of "lesser" languages. Bit like XML introduces a significant fraction of Lisp SEXPs to other languages, but makes it seem a bit more laborious so you can pretend to be doing hard work
Also, a large library of pre-defined aspects is presumably a goal. Just as the strength of Java is mainly in its standard libraries, not it's mediocre language, a large set of standardised aspects would be better than sitting down with MOP and writing them yourself from scratch, even if CLOS/MOP is ultimately more powerful.
That's a fun method. I don't see how it would work if things like "endl" were injected into the stream (or other functions/constants which return an ostream), but you probably just omitted that kind of detail. However
3. The compiler should optimize out the "log" variable if debugging is turned off, but leave the "side effects" (e.g., "++i" in the above example).
An interesting technique, and I see it offers protection against someone accidently changing program behavior when log outputters have side effects. But, they shouldn't be doing that.
Depending on side effects is sometimes a bad idea- especially if those side effects occur in a line that is primarily user-visible output. Suppose a someone decides the log doesn't need to show the value of "i" anymore. He's got to move the ++i somewhere else.
If the ++i is needed for the function to be correct, I really think it should be kept away from the logging message. (There remains a moderate chance that a person pursuing a bug will want to see the log output from some functions, but not all of them, and will just throw "//" in front of those messages he doesn't want. Then the side-effect is gone again)
As far as "compilers should optimize it out": many C++ compilers optimize less than it seems they should, especially if the classes are in separate object files. Keeping logger in a h++ file avoids that, and hopefully the compiler will notice when it is by inlining an identity function and remove it completely.
About the only thing it might not optimize is the 1-4 bytes of extra stack used for the play_logger in each function. (Even though the object has no members, it still needs some space, if methods will be called on it). That won't matter to anyone with a "real" computer.
Their new guildline for variable-naming in .NET is to not use variable type notation.
Doing otherwise would be braindead, dotNET is all about OOP if I'm not mistaken.
So, as soon as you cast or convert a hungarian-notation-compliant reference it would be lying about it's objekt.
Hello confusion!
Imagine the horror of maintaining that code.
Anyway, I am sure a lot of prople coming from VB backgrounds and not groking OOP will make this very mistake.
I pity the one that has to maintain the crud they will produce...
"First lesson," Jon said. "Stick them with the pointy end."
Thank you for the -1! Ah, how sweet to be an anonymous coward!