From: Alexandru Popescu Date: 2005-10-21T04:25:31+09:00 Subject: Re: [RCR] Cut-based AOP #: Trans changed the world a bit at a time by saying on 10/20/2005 6:36 PM :# > 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. > Sorry that I have to say it: no it doesn't support. Should we talk about aspect instantion strategies? Should we talk about field read/write access? Should we talk about flow based pointcuts? Probably this will give raise of an answer that these can be achieved doing X or Y trick. I agree. But the principle behind a framework should be not to require another tricks for making it work. >> 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. > I have said it too many times: I am not a Ruby dev, so this one line of code pointcut support is not clear to me. Can you help me out? I want a pointcut that will match all calls to a db operation method so that I can crosscut the transaction concerns. >> 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). > Before and after advices can be seen as subset of around, but (at least) theoretically speaking they are not. The around advice is the only one that can control the program flow; the others are not. I am not aware of what are those percentages: 99/1 means that out of 100 pointcuts 99 are execution pointcuts? >> 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. > > > You don't even want to expose conditionals, or some weird (and unstable) points in program execution. ./alex -- .w( the_mindstorm )p.