I'm sorry I've spoke without thinking in regards to Zend Framework 2, I'll try an refrain from such comments next time unless it's relevant to a the particular argument/discussion.
On Monday, December 3, 2012 12:58:33 PM UTC+2, Fabien Potencier wrote: > > On 12/3/12 12:00 AM, 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, > > I agree with that. > > > 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:> > > <mailto: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 <http://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:> > > <mailto:symfon...@googlegroups.com <javascript:>> > > To unsubscribe from this group, send email to > > symfony-devs...@googlegroups.com <javascript:> > > <mailto:symfony-devs%2bunsubscr...@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 > > 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
