Like having event dispatcher implemented as an extension, like twig c extension?
Is event dispatcher slow anyway? Or anyway room for performance improvment? Le 3 déc. 2012 08:26, "Larry Garfield" <la...@garfieldtech.com> a écrit : > Drupal dev here. :-) Drupal has been accused of being "procedural AOP" > before, and not entirely inaccurately. > > Be very careful with that. AOP is a flame thrower; very powerful, but can > also burn you quite badly. If you're not extremely careful, it can make > effective unit testing next to impossible. > > That's not to say don't use it, but coming from a system that is built > around AOP principles... I would not recommend baking full-on AOP into > Symfony. Rather, let's just make events faster so they're cheaper to use. > > --Larry Garfield > > On 12/03/2012 01:01 AM, Victor Berchet wrote: > > Florin, > > What a nice rant ! > > But as for most rant, only a few lines of you message is relevant (the > other having been treated in previous message or being non-argument) let me > handle them: > > - "comments": annotation is one way to configure AOP, use php/xml/yml if > you like, > - "writing events instead of comments": > - you can use AOP with 3rd party libs that do not use events > - you won't have the overhead of dispatching an event if no listeners is > attached to the events (ie you can logging in your debug environment that > has 0 impact in your prod env). > > As I state in my second message, my intention is more to promote AOP > than to have something in Symfony. You seem to be this kind of people that > have problems with (not so) new concepts, you can go read me first message > again then ! > > The only part of your message I like is "I'll change my mind". > > For #2679, I don't really see how it relates with AOP nor why it is a > bug - As a reminder the issue state that http://admin-zone/<any url> > should return a 403 even if <any url> does not correspond to an existing > route. It currently returns a 404 if the route does not exist. This is > because the routing is now triggered before the security, for good reasons. > > Cheers, > Victor > > Le dimanche 2 décembre 2012 22:29:55 UTC+1, Florin Patan a écrit : >> >> I got a question for you as well as for the rest of the community :) >> Do you really needed? >> Is is something that you can't finish your project without? >> >> I'm not saying AOP is bad, the main scope is quite nice on paper, >> academically, but also OLD! Some references for AOP date back to 1994-5. >> I have to admit, until hearing about it from Victor, I didn't had a clue >> about it, now I just know what it is but I won't use it. >> Why? >> Simple. I don't want more layers of abstractions between my original code >> and the server. I want to keep it as simple and clean as possible even if >> it means that I won't be able to write comments that are shorter that the >> plain old code. Plus, as far as I can tell, I could just as well be using >> events for my needs instead of comments, or maybe I just didn't got the >> full view of it. What would that be good for, writing events instead of >> comments?!? Maybe I just want to have better traceability for the code. >> Maybe it's better to know that if I write a piece a code, the other people >> that will come after me when I'm not there, will be able to see __CODE__ >> not comments or code hidden somewhere else. I want to be able to see what's >> going to be executed as much as possible. >> >> Ok, so there'll be a AOP extension. GREAT! Now convince the sys-admins >> to install it. More over you know what they'll ask? Is this safe? Does it >> crash under load? does it block something? Can it have memory leaks? Is it >> threadsafe? Can't you program without it? >> And if you've never heard those questions about __ANY__ third party or >> even PHP extension then either your sys-admins don't care, don't know, do >> extensive tests and know what you need it for/how it works better that you >> or you simply didn't worked into a enterprise environment. >> >> So we have this already, Doctrine is using annotations, Symfony2 is >> doing it and so on but the question stands: Do we __REALLY__ need? In the >> framework? When everyone on the industry wants faster frameworks, easier to >> use features from the frameworks, a better/faster PHP engine and so on? Is >> it stopping Symfony2 from being waay faster that Zend Framework2? Is it >> stopping Symfony2 to be clean and relatively easy to pick up by new people? >> >> I know, once you've found a new toy you'll see it used everywhere but >> you always have to ask yourself: do I really need it here? Is PHP suited >> for AOP? Do I need a way to change the classes at runtime? Do I need a way >> to hide the implementation from the programmer who'll then spend hours >> trying to debug something that he doesn't understand? >> >> And maybe the most relevant case, can you explain me __WHY__ do you >> need it in the framework? And if you are going to say: enforce SRP then >> please don't. Just because you write it somewhere else then compile it at >> runtime/cache time and write a comment for it it doesn't mean you got your >> responsibilities separated, it means that you just managed to perform the >> illusion of separating the concern to the end user while introducing him to >> whole new level of where's this executed and why is this not performing >> what I want??? >> >> But I guess we indeed need another layer of abstraction/design >> pattern/paradigm in PHP, which is supposed to be simple, clean, fast, not >> like Java, or insert your clearly more preferred language here, which has >> all those cool features that we can't play with in PHP :( If you like so >> much coool things, just look at the mess that Zend Framework 2 is. >> And if you like AOP and want to help, can you debug and fix this please? >> https://github.com/symfony/**symfony/issues/2679<https://github.com/symfony/symfony/issues/2679>my >> mortal skills aren't enough to understand the Security component to fix >> it. >> >> Maybe when PHP will have native support for the features needed to do a >> clean AOP implementation, I'll change my mind (for sure), or maybe that >> will happen faster then that. Who knows? :) >> >> Just my two cents from a non-academic / theoretic point of view. >> >> >> >> Best regards. >> >> >> >> On Thursday, September 30, 2010 8:42:16 PM UTC+3, Yuen-Chi Lian wrote: >>> >>> Hi, >>> >>> I searched the entire group but couldn't find many discussions on AOP. >>> >>> The SF2 Security discussion (http://bit.ly/sf2sec) got me to wonder >>> will AOP ever be part of SF2. If yes, are we going to write it all or we >>> will use the state-of-art AOP solution in PHP (which is?)? >>> >>> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
