From: David Pollak Date: 2006-06-15T02:29:12+09:00 Subject: Re: Cut-based AOP ------=_Part_75514_3552014.1150306148480 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks, Aspects are bad (but perhaps a necessary evil in Java) and Ruby doesn't need them. Aspects provide a theoretically interesting facility to insert code around methods or around calls to methods. They provide meta-programming facilities to Java, a language that was designed for type-safety and without meta-programming in mind. In my experience, Aspects have been used by Java developers during development/debugging to "figure out what's going on" with calls to particular methods. Aspects provide a nice set of runtime debugging tools that allow the developer to trap and trace particular calls and/or call patterns in a way that simply setting a breakpoint cannot do. Aspects work pretty well for this application. Aspects are also used to add "features" to existing classes. The prototypical use in my experience is to add transactions into a series of JDBC (database) calls that didn't have transactions before. To the extend that the source code for the original libraries is unavailable or infeasible to change, Aspects work okay to patch code. However, Java's execution model and gestault revolve around execution predictability. Once I write, test, and deploy a class, the execution of the class and its side effects are knowable and verifiable. This is good from a security and testing standpoint. This is perhaps Java's greatest strength for large-scale projects. Aspects destroy this model and fundimentally weaken Java. Depending on the Aspects in use during development, during testing, and during deployment, execution of well tested code can change and not work correctly. The model for describing Aspects is broken and can lead to over-broad application of an Aspect such that code is unintentionally broken because of the way an Aspect is described. Ruby doesn't need Aspects. Ruby's open class structure means that any code can perform necessary surgery on an existing class in a well defined, well understood fashion. Ruby's meta-programming facilities (alias_method, open classes, etc.) allow a Ruby developer to wrap methods from other classes, redirect execution, etc. in a predictable, programmatic fashion. Ruby has the meta-programming facilities to provide method wrapping, logging, performance monitoring, etc. My 2 cents. Thanks, David On 6/14/06, Austin Ziegler wrote: > > On 6/14/06, Ruby Newbie wrote: > > Looking around, you have hundreds of posts, and you're involved as a > > mentor in Google Summer of Code "Automated Wrapper Generation for > > Information Extraction" arena. I take it you have the experience to > > back up what you're saying. > > I like to think I do, at least. I will freely admit that I don't "get" > AOP. I *understand* the reasons for AOP (adding logging for something > you no longer necessarily have source access to, for example), but I > have *long* felt that AOP is a pure hack. > > > Can you provide references to better and more-established ways of > > offering such extensibility? I looked briefly at traits which you'd > > alluded to earlier, but it requires changes to the core code for > > trait/hook insertion. I'm interested to read about other mechanisms > > which are more maintainable and extensible than AOP in Ruby if you > > could please share them. > > If you control the source, write the source better. If you *want* > extensibility points, provide clear hooks. > > class Foo > def bar > pre_baz if respond_to? :pre_baz > baz > post_baz if respond_to? :post_baz > end > end > > Matz will be providing (somewhat) cleaner ways to do this, but that's > the essential nature of the beast. It's a form of plugin-style > programming and that's well understood, while AOP is a poorly defined > and easily misunderstood beast. > > Similarly, mixins provide the main capability that Ruby needs -- but the > original programmer has to write the code to be able to deal with this > properly. And if they don't, you can always inherit or compose. > > I think that it's important to note that *even now* (five years on from > the PARC research) you can't find many clearly-written, concise > explanations of AOP and why you'd want it. It's all buzzwords. > > AOP may be valuable. But I have yet to see anything that convinces me > that it's worth all the bother. It's sort of like Inversion of Control. > Interesting, but not relevant to most (98%+) needs. > > -austin > -- > Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ > * austin@halostatue.ca * http://www.halostatue.ca/feed/ > * austin@zieglers.ca > > -- -------- David Pollak's Ruby Playground http://dppruby.com ------=_Part_75514_3552014.1150306148480--