From: Alexandru Popescu Date: 2005-10-20T23:33:19+09:00 Subject: Re: [ANN] [RCR] Cut-based AOP #: Christophe Grandsire changed the world a bit at a time by saying on 10/20/2005 2:20 PM :# > Selon Alexandru Popescu : > >> >> While, maybe leaving alone all these aspects, may be a Ruby implementation >> constraint, they are >> valid AOP principles that will miss from the implementation. >> > >>From the rest of the discussion here about this RCR, I have understood (and > Trans or others can confirm it I think) that cuts are supposed to be a *basis*, > on which fully-fledged AOP can be built, in a way that fits with Ruby, since the > base itself fits with Ruby. It's a bottom-up approach, instead of the top-down > approach that for instance AspectJ took, and which makes it look very alien to > the rest of Java (in my opinion). I personally believe it's the best approach, > which is why I voted for this RCR: first built the tools you need, then use > those tools to create a framework. This is in my opinion the only way to get > something eventually stable and useful, without looking too much like an add-on > but really like part of the language. > > In other words, the RCR isn't here to propose full AOP in one go. It is there to > provide what the authors think (and so far I agree) is the only construct > missing to built fully-fledged AOP, in a way that doesn't break with the rest > of Ruby, and is easy enough to implement. I guess (but never having used it I > might be wrong) that full AOP could be built then as a standard library, built > on cuts and ObjectSpace, and/or Ruby's already existing reflection capacities. > > I am always in favour op bottom-up approaches. They may sometimes seem slower, > but on the long term they result in better code, especially when each tool and > addition is built as independently as possible. In a top-down approach, people > seem often far too tempted to look at their project as a single whole, and thus > to build it in such a way, resulting in code which after some time gets > unmanageable. > > I am really in favour of cuts (or maybe some other way to implement the same > concept, using modules like matz suggested), because they provide a strong, > stable foundation, on which not only AOP can be built, but who knows what more? > Cuts extend the notion of modularity in a way different from simple modules, and > this could very well lead to plenty of other things besides AOP which is the > main issue they were built for. In other words, don't get too blinded by the > issue of fully-fledged AOP when you review this RCR. See it as foundation for > it, and maybe quite a few other things. > -- > Christophe Grandsire. > > http://rainbow.conlang.free.fr > > It takes a straight mind to create a twisted conlang. > > I would probably agree with you with some small exceptions: 1/ AspectJ was alien to java because it was meant to provide a full AOP implementation. Meanwhile, considering AJ alien is like saying cut-s are alien to ruby, just because they are trying to introduce a new idea. 2/ in a bottom-up approach as you are considering the cut-s approach, you can miss some of the top views. And this will result in the impossibility to have this top scenarios implemented or working. 3/ if you consider cut-s just an implementation aspect of AOP support in Ruby, than I will agree that it looks quite appealing. But I have read a full set of examples which are based directly on them. I wasn't able to see pointcut definitions, and without them - as I already pointed - there is no aop. I am not trying to argue on the main idea or on the effort this RCR took. It is indeed a fantastic effort and I appreciate it. I just feel that some aspects should be considered right from the beginning instead of just ignoring them. We have the advantage that other solutions are pretty advanced at this moment and learning from their past is a good thing to do. respectfully, ./alex -- .w( the_mindstorm )p.