Again, starting with saying sorry for the ZF2 remarks. Now back on topic. I've never said that AOP is bad for what it tries to solve. It's actually quite a nice principle.
My problem with it is the current support for it. Things are not yet production ready on a large scale as far as I've seen and having a potentially unstable technology in a mature framework (Symfony2 is almost 1.5 years) could have some rather undesired effects when used in production systems. For a comparison, look at MongoDb which is a relatively young technology, it's adopted more and more but unfortunately they've realized that their API needs more love, which in turn will mean many changes for the upcoming 1.3 of their extension. Maybe AOP could be considered for Symfony3 or later, like Fabien said that he's open to bigger changes but for 3 branch only, and this feature would make perfect sense there/then imo. Maybe by then we'll get some better support from the current developing extensions or even (wish) from PHP itself :) I don't want to stop anyone from learning new things, like I've said, I learned about this when Victor suggested the first time, but many people don't have the skills to filter out the use cases for this, and that would be dangerous for the eco-system as well. With more people turning to PHP (again) for the things we can do faster that other languages and with PHP getting more traction in the enterprise level thanks frameworks like Symfony2 or Zend Framework 2 (and maybe others, for sure) I think we should think first on stability then what's the trade-off if we introduce potentially unstable features vs coolness factor. Maybe a project can afford 10 minutes of downtime from time to time, but both in my current company and previous one, anything less that 100% uptime was a failure from __all__ people involved in it. Would you like to assume that responsibility for the entire userbase of such a big project?!? Or should I quote your 'shall we all stop and spend our time fixing current code? Is it not allowed to build new code on new concepts?' , I won't even bother to reply to that statement but try saying that to my manager :P I'm not saying that we all must stop, but sometimes, bugs / potential bugs are more important that cool features :) And if not to the enterprise users, then to whom do you want to address? People doing Wordpress themes (themes !== plugins, Wordpress plugins would be a great use case for Events/AOP) and calling them new websites?! And yes, any bundle could implement this missing feature, but for the core I think we should get the maximum out of the current features, like your proposal for lazy loading for container dependencies and many great things be it from Symfony2, Zend Framework 2 or other projects and libraries. Help the FIG guys make decisions on things like logging interface, cache interface, something interface and so on, there's plenty of potential currently not exploited to the fullest just because people find new toys and sometimes the current toys are hard to understand by us kids :) Best regards. On Monday, December 3, 2012 1:00:03 AM UTC+2, Marco Pivetta wrote: > > @Florin: I'm not sure I understand your rant, but are you implying that > implementing a new feature that opens new ways of implementing base > functionality such as caching and proxying method calls is bad? > > AOP solves a bunch of problems by reducing complexity from O(n*m) to O(n) > (see https://github.com/AOP-PHP/AOP/issues/3 ) and you can't simply > ignore that. > > It maybe doesn't need to be integrated in the framework, since any bundle > would do anyway, but I don't see a point in trying to stop people from > implementing well known and well working patterns. > > It is also unclear why you are pointing to a routing issue to justify why > people want to develop new stuff: shall we all stop and spend our time > fixing current code? Is it not allowed to build new code on new concepts? > > Also, please stop all the ZF2 bitching, > > Sincerely, > > Your usually lurking ZF2/D2 dev > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > > On 2 December 2012 22:29, Florin Patan <flori...@gmail.com > <javascript:>>wrote: > >> 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 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 symfon...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> symfony-devs...@googlegroups.com <javascript:> >> 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
