On 26.Aug.2003 -- 06:43 PM, Stefano Mazzocchi wrote: > > On Monday, Aug 25, 2003, at 10:10 Europe/Rome, Christian Haul wrote: > > >On 23.Aug.2003 -- 03:48 PM, Stefano Mazzocchi wrote: > >> > >>On Saturday, Aug 23, 2003, at 10:17 Europe/Rome, Christian Haul wrote: > >> > >>>Stefano Mazzocchi wrote: > >>>>On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul > >>>>wrote: > > > >>I'm not suggesting we add AOP to Rhino, I'm suggesting we add the > >>ability to avoid concern crosscutting in the cocoon flow. > > > >After reading Nicola Ken's message I believe this discussion is void > >but I still would like to explain my position as it appears it hasn't > >been clear enough. > > > >I've started using flow very shortly after the javascript incarnation > >arrived and I love flow. That is 1+ years using flow. I believed that > >adding AOP to Rhino (which happens to be the javascript engine in > >Cocoon) is beyond the scope of this project. Now you explained you > >don't want to do that but only add it to the invokation of flow > >functions. I believe that is a poor solution and does not provide > >enough usefulness to solve any of your examples but the authorization > >one. > > I can hardly disagree more. When you have function interception you > have all you need to implement layers of invocation (and some people > call those layers "aspects", but I don't). This solves all the issues I > previously listed (including, yes, AAA).
Stefano, could you *please* explain what you are talking about? It appears that every time I try to rephrase your intentions you say, you are talking about a different thing. According to your mails, you don't want to * add aspects to Rhino * add interception only to flow invocation Where do you want to add your interception then?? > >However, as I said above, after reading Nicola Ken's mail I believe > >this dicussion is void because it appears AOP in javascript is as easy > >as saying "aspect". In addition, I believe his proposal for aspects in > >the sitemap is balanced and very interesting. We should follow this > >idea further. > > I think we are talking about two different things here. Indeed, Nicola Ken's mail contains to different concepts. The first reads like a solution for aspects in javascript while the second is a completely new proposal. The reference to AOP fun with javascript is great. The proposal is very interesting. > One thing is layering flow, another thing is layering pipeline > definitions. > > If you allow me to remove actions from the picture just one second, > you'll see how layering pipeline definitions might allow you to > simplify (or ease reuse) of pipeline definition fragments, but you also > understand how this is not going to help you on things that touch > resource flow rather than resource production. This is no either-or situation. Why can't we have Nicola Ken's proposal and use the Aspects.js he references as well? > Note: I stay away from the name "aspect" because it's a overhyped > concept and too blurry to be used as a meaningful terminology because > it means different things to anybody. Adding new names does not help either. IMO is the problem of aspects in flow solved by the existence of Aspects.js see http://freeroller.net/comments/deep?anchor=aop_fun_with_javascript Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
