From: Trans Date: 2005-10-21T01:36:59+09:00 Subject: Re: [RCR] Cut-based AOP Hi-- Alexandru Popescu wrote: > Hi! > > I would like to comment on this proposal. I can agree right from the beginning > that the points here will be presented from a not-so-rubiesc perspective. > the proposal looks like an method-interception framework, rather than a > full blown aop solution. Yes, in a way you are correct. Ruby provides enough reflective functionality that it is not neccessary. In other words there is no need for what you call "full-blown" aop b/c the system already supports all that is neccessary to achieve full blown aop. This is not to say there are no areas in which it can be improved, indeed there are. Cuts is one of those. Peter and I already have developed much of the rest too: ways to strengthen the hooks and callbacks as well as better EAOP (event-based AOP) than provided by set_trace_func. But these are for another day, and more importantly, they do not cover the the majority of AOP usecase, which Cuts squarely target. > The proposal is mixin together theoretical aspects of aop with Ruby specific > implementation problems. I would disagree completely. The proposal narrows down the core of AOP (namely the 2nd form of AOP implemention) to a formal OOP construct. The Cut can be implemented in any OOP system, from Simula 67 to Smalltalk. In fact this has been all along and still is Very Important to me. I did not want a construct suitable only to Ruby, but something generally applicable. > While this cannot be considered a real problem, what I have noticed is that one of > the main concepts of the AOP pointcuts are completely ignored. Pointcuts are mentioned, and why there is no need to have a special "pointcut thing". Pointcut is a concept of selecting joinpoints --another abstract term, meaning the place in code to intercept. Well, we have exactly that. You can specify on small scale of one class and it's methods, or large scale using ObjectSpace. It is not neccessary to make a pointcut thing when we already have those. But if you want you could write your own extermely easily, probably in one line of code. > The main idea behind AOP is to be able to define crosscutting concerns. This looks > pieces of functionality that can be used disregarding the OO nature of the > project. Sorry, I do not full understanding. We do address crosscutting, and OO nature. > While at the first glance the method interception mechanism is one of most > important aspects of AOP, there are a few distinction that must be considered: > call vs execution, before, around, after pieces of advice. before and after advice are subset of around advice. We decided it was just easer to have the one than worry about three since before and after are merely sugar of around. You are right about call vs. execution though. In this case it a matter of the 80/20 rule. We make 80% of the need easy (though it's probably more like 99/1 in this case). If you _must_ have call interception then there are more advance techinuques to use, such as set_trace_func. We've also discussed method_dispatching hook. But understand these have much greater impact on performance than method interception. This is important reason call interception is not specifically part of this RCR. (But who knows? Maybe someone will come up with an easy idea for this too). > While, maybe leaving alone all these aspects, may be a Ruby implementation > constraint, they are valid AOP principles that will miss from the implementation. There are some. Because Ruby is not 100% OOP, though it is very close, you can not cut conditionals for example. You've pointed out call interception already and there are other marginal areas. Ruby itself has some limitations that effect this. Combined with Ruby's ability to reflect on itself, Cut-based AOP covers the vast majoirty of AOP needs. And as Ruby improves so does the reach of cuts. T.