I don't agree. I think that SOA gets you back to functional programming j/k ;-) (http://c2.com/cgi/wiki?ServiceOrientedArchitecture)
Normal every day AOP is nothing more than the dynamic invocation of the common decorator pattern. Meaning when you use dynamic proxies for instance: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Proxy.html http://jboss.org/jbossBlog/blog/acoliver/?permalink=0012.html http://c2.com/cgi/wiki?DecoratorPattern What are you doing? You're just adding existing functionality. Its totally OOP. The only thing AOP about it is that we can apply this technique to define this at deploy/runtime rather than compile/link time. Big whoop. What makes this nifty is that through tools like Java Assist we can even extend/create the interface. We can even do this *without* an interface. Add to this an expression/pointcut language and we can add all kinds of functionality. I don't see what defines this as functional programming at all. Now you COULD use this to "functionalize" things I suppose. I see AOP as a marketing word for something rather simple that has nothing to do with object-orientation or functional-orientation. In its most basic form (Jboss 3.x.x already uses this to implement the entity container), its a way to build up a composite object made from decorators. -Andy > From: "David Spitz" <[EMAIL PROTECTED]> > Reply-To: "Research Triangle Java User's Group mailing > list."<[EMAIL PROTECTED]> > Date: Tue, 6 Jul 2004 21:16:40 -0400 > To: "'Research Triangle Java User's Group mailing list.'" <[EMAIL PROTECTED]> > Subject: RE: [Juglist] Structured Exception Handling > > > The cynic in me might interpret that as a condemnation of OOP. As in, AOP is > how to get back to functional programming without admitting it. And, I would > agree with you! :) > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Tuesday, July 06, 2004 8:57 PM > To: [EMAIL PROTECTED] > Subject: Re: [Juglist] Structured Exception Handling > > The problem with such dogma is the question of "system". For instance, suc= > h > advice does me little good if JBoss is considered "system". > > As for the API, that=B9s essentially what I was saying. The issue being of > course the "continue". > > Meaning if=20 > > Public void myMethod() requires exception(Connection c) { > doFailableOperation(); //"exception" thrown here > doOtherStuff(); > } > > Public void myOtherMethod() { > this.myMethod()(this.brokenConnectionHandler(c)); > } > > Public void brokenConnectionHandler(Connection c) { > //handle broken connection > > now what?? Return?? Continue?? > } > > VB had "on error" for code blocks. Like "on error goto errorHandling" and > you could call "continue" but where would you be??? It was too ambiguous o= > f > scope (its been years since I did VB so excuse me for blocking most of the > memory out if this isn't 100% accurate). > > Yes, I work for Jboss. AOP can of course save the world because Chip said > so. However, I wonder if this might be a good place for AOP. Meaning > attributes and point cuts for *if* you want to handle the exception. And > you the developer can bind the exception handling *later*. Of course again= > , > ambiguity and the potential of *forgetting* could be a problem. However, I > wonder if in most cases, the best practice ought not be "fail fast" error > handling. Meaning if the file isn't found, throw up and die. If that=B9s > no= > t > good then the user needs to add @handleError myErrorHandler() which will be > called instead of "throwUpAndDie()" or something. > > Anyhow this is fun if not a little academic. > > -Andy > >> From: "David Spitz" <[EMAIL PROTECTED]> >> Reply-To: "Research Triangle Java User's Group mailing >> list."<[EMAIL PROTECTED]> >> Date: Tue, 6 Jul 2004 18:57:12 -0400 >> To: "'Research Triangle Java User's Group mailing list.'" <[EMAIL PROTECTED] > .org> >> Subject: RE: [Juglist] Structured Exception Handling >> =20 >> =20 >> Several years ago, I read a paper written by someone in the Navy whose >> controversial claim was that programmers should stop writing error handli= > ng >> code. His point, however, made some sense: mainly, that error handling co= > de, >> by its very nature, is rarely tested sufficiently (if at all), and is >> therefore usually the source of a disproportionate number of errors. That >> is, if most error-handling code is buggy anyway, why bother? Let the syst= > em >> deal with it. >> =20 >> I don't recall the details of his argument, or the author's name, nor did= > a >> cursory web search turn up the paper. Perhaps someone knows the paper to >> which I'm referring. >> =20 >> Personally, I like the Java approach of providing checked and unchecked >> exceptions. There ought to be a mechanism for forcing API users to deal w= > ith >> "expected exceptions" (for example, broken network connections), while no= > t >> forcing lazy (or efficient) programmers to deal with problems they can't >> normally handle anyway, such as out of memory errors. >> =20 >> Regards, >> David >> =20 >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Cory Foy >> Sent: Tuesday, July 06, 2004 2:19 PM >> To: Research Triangle Java User's Group mailing list. >> Subject: [Juglist] Structured Exception Handling >> =20 >> As I got involved in the .NET world, one of the things that bugged me >> (among lots of other things) was that classes didn't require you to >> specify or catch exceptions that it created. So even if I wanted to >> specify that my account class could throw an "AccountOverdrawn" error, I >> had no way of decorating the class to make it evident, nor had a way for >> users of my class to be aware or indeed even note that my class could >> throw it. >> =20 >> In my mind this is a limitation of .NET over Java. Someone then directed >> me to an interview by Anders Hejlsberg, the chief architect of C# >> (http://www.artima.com/intv/handcuffs.html). In it both he and Bruce >> Eckel agree that structured exception handling is not a good >> methodology, but the reasons they give left me wanting more. >> =20 >> The basic comments seem to be that programmers are lazy, and if you want >> to have a class that inherits from 10 different classes each with 8 >> structured exceptions they can throw, the lazy programmer is just going >> to write "catch (Exception e)" and be done with it. They do raise some >> interesting comments about extensibility and being able to modify base >> classes though. >> =20 >> I've seen some pretty bright minds on this list and am really interested >> in what you all think about exception handling. Is it a good thing or a >> bad thing to be able to force using classes to at least acknowledge >> exceptions? >> =20 >> Cory >> =20 >> _______________________________________________ >> Juglist mailing list >> [EMAIL PROTECTED] >> http://trijug.org/mailman/listinfo/juglist_trijug.org >> =20 >> =20 >> _______________________________________________ >> Juglist mailing list >> [EMAIL PROTECTED] >> http://trijug.org/mailman/listinfo/juglist_trijug.org > > > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] > http://trijug.org/mailman/listinfo/juglist_trijug.org > > > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] > http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
