From: Christophe Grandsire Date: 2005-10-20T21:20:36+09:00 Subject: Re: [ANN] [RCR] Cut-based AOP 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.