Dear Victor I'll try to answer to each question. My English is not good enough, so there will be mistakes, please ignore them if possible ))
1. Your shouldn't use AOP for any __APPLICATION__ logic. AOP should be used only for simplifying the source code of your services by extracting logging, caching, authorization, transaction, etc into specific classes - aspects. Main idea here is DRY - do not repeat source code for logging/caching something in each method of the class. 1.1 It's not too complex. It's like OOP with objects, classes, encapsulation, polymorphism, etc. Of course, it will take a little of time to read about terminology, play with AOP, but after that every coder will easily understand you. 1.2 Yes, AOP contains some magic to perform weaving, but this is power of aspects: you can easily add/remove aspects and everything should work. I'm not want to use PHP extensions for bytecode modification, because it can give unpredictable results or even segfaults. Of course, sysadmins doesn't like any strange extensions on production servers. Go! library is fully PHP native, so it can work everywhere. And yes, DI is much more magic component ) Event dispatchers, signal slots, dynamic proxies they are magic. But when magic has a predictable result, it becomes standard ) 1.3 Debugging. Debugging an aspects with Go! AOP or with AOP-PHP is straightforward: just put a breakpoints in aspect classes or in object classes. And just refresh a page with enabled XDebug. TYPO3 Flow AOP replaces original files with proxies therefore there will be need to put breakpoints in cache files. Not so good. 1.4 Performance Performance of PHP-AOP is the best because it's an extension, but no warranty that this extension is stable enough. Go! has good performance for method invocations like CG (JmsAOPBundle) and even more faster ) It doesn't use slow technologies during method invocation. I have a solution that will allow to cache proxies in another directory and will preserve an ability to debug source code, not the cache. 2 AOP. Past? Present? Future! I think, that symfony2 takes a lot of ideas from Java, especially from Spring framework. IoC, DI, definition for services in XML - they all were ported to PHP by Fabien. However, Spring has also an AOP and it's a great technology, that can be ported to PHP too. So, Go! is a __LIBRARY__ that can be used everywhere, like DIC Component. Just add one line to composer, install it and you are ready to use aspects.There isn't any requirements for PHP extensions, frameworks, technologies that you use. It's main key of aspects, they should be simple as possible and shouldn't require anything specific from application source code to work. 2.1 Thanks for compliment, I am 27 years old )). And my title is Senior Web Architect at Alpari ) Two days ago I were at Kiev, Ukraine at SymfonyCampUA-2012 and presented this library to the Symfony Community. Storm of applause and respects after presentation made me so happy )) Here is one photo with me: https://plus.google.com/photos/102759111128192312564/albums/5817101515573489169/5817102228448987362 Slides (Russian) are here: http://www.slideshare.net/lisachenko/php-go-aop (Pictures can give you the overview what Go! can do) If you have more specific questions about AOP or want to discuss something feel free to ask me, i'll be glad to talk about AOP and improve my English too )) суббота, 1 декабря 2012 г., 4:30:26 UTC+4 пользователь Victor Berchet написал: > > Dear Alexander: > > Ah AOP, you should learn that the Symfony community is a big and beautiful > family but only our beloved father, Fabien is allowed to introduce new > concepts. > > Don't worry I am kind of joking but nonetheless I think that AOP has quite > a bad reputation in the community, see [1][2] and the previous messages in > this topic even if they are older. > > So I would like to take the opportunity to talk a little more about AOP. > > 1) Why I should not use AOP (common biases) > > 1.1) It's way too complex > > It's a 3-letter word. DI, the central concept of Sf2 is only a 2-letter, > it must be complex ! > And the extensive new terminology[3] is there to prove it. > > 1.2) It is a way way way too magical paradigm (def: to transform or > produce by or as if by magic) > > Most developers are afraid of AOP because they think it's some kind of > black magic. > > They probably do not know that Sf2 uses a lot of magic, let me quote a > comment[4] for a recent discussion[1]: > > > did you ever wonder what happens when you run your 10 lines controller ? > > > > - autoload: generated code, > > - bootstrap: processed code, > > - DI usage: generated code, > > - route matching: generated code, > > - maybe some security: generated code, > > - your 10 lines of genuine code, > > - maybe some ORM: generated code, > > - URL generation: generated code, > > - probably some Twig rendering: generated code. > > > > But maybe none of this happens because you're using HttpCache... > generated code ! > > I could add that by default in the Sf standard edition[5]: > - Doctrine entities manager are all proxied[6], > - The security extra bundle also generates proxies[7]. > Yes a lot of devs are already using AOP without even knowing. > > To me $this->get('security.context')[8] has more magic than AOP > > 1.3) It's hard to debug > > Try to debug "$this->get('security.context')" or "$dispatcher->dispatch()" > that triggers a lazy-loaded service, > it will be much more complex that debugging AOP which only add a very > light proxies to your classes. > > 1.4) Performance > > The generated proxies are very light and the impact on performance is very > small. > And you should balance it with the improved maintainability of your code > which is priceless. > > 2) so AOP ? > > 2.1) What AOP could do for you ? > > "A plugin should be able to add methods, or do something before or after a > method is executed, without interfering with other plugins[...]" > This is not a quote from the AOP article on wikipedia, but from the Event > Dispatcher component documentation[9], the concepts are somehow similar. > > With AOP you can execute some code (Advice) after or before a function (at > Join Points). "Pointcuts" are a way to express at what "Join points" the > "advice" should be executed. > This is a very incomplete definition, just to give you a taste of AOP and > the willing to dig deeper. > > 2.1) Is it complex ? > > No, even a 14 years old boy[10] can understand it (sorry Alexander, an > other of my bad jokes - or maybe a compliment actually - but you look damn > young !). > > There is only a handful of concepts, you can try playing with it inside > your SFSE, go read the docs[11] and start playing. > > 3) Any current implementation ? > > AOP has first been introduced in Java with AspectJ[12] in 2001. > Qooxdoo (a great javascript UI library) also supports AOP[13]. > > Actually a lot of languages[14] supports AOP, it must not be that bad ! > > but what about PHP ? > - Typo3 uses it since 2006[15], > - There is a PHP extension[16] - unstable for now but some work > ongoing[17], > - Johannes has a bundle for Sf2[18], which is included in the SE, > - Alexander has written Go[19]. > > Well, that's it for today. > I hope some of you have learned a few things and will give AOP a try. > Maybe we'll have an AOP component in Sf2 some day. > If not, not a big deal, I had a great time writing this message anyway ! > > Victor > > [1] https://github.com/symfony/symfony/issues/6139 > [2] https://github.com/symfony/symfony/pull/3296 in some extends > [3] http://en.wikipedia.org/wiki/Aspect-oriented_programming#Terminology > [4] https://github.com/symfony/symfony/issues/6139#issuecomment-10841221 > [5] https://github.com/symfony/symfony-standard > [6] look at your <cache>/jms_diextra/doctrine/ > [7] look at your <cache>/jms_diextra/proxies/ > [8] > https://picasaweb.google.com/victor.berchet/Sf2?authkey=Gv1sRgCM7A8tqJoc_zywE#slideshow/5816753838641482210 > [9] > http://symfony.com/doc/current/components/event_dispatcher/introduction.html > [10] > https://secure.gravatar.com/avatar/e7af3ef8e48a800cd2eedae073104c1a?s=400&d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-user-420.png > [11] http://jmsyst.com/bundles/JMSAopBundle#overview > [12] http://www.eclipse.org/aspectj/ > [13] http://demo.qooxdoo.org/current/apiviewer/#qx.core.Aspect > [14] > http://en.wikipedia.org/wiki/Aspect-oriented_programming#Implementations > [15] https://twitter.com/robertlemke/status/274532529975984128 > [16] https://github.com/AOP-PHP/AOP > [17] https://twitter.com/julienPauli/status/274180211132755968 > [18] https://github.com/schmittjoh/JMSAopBundle > [19] https://github.com/lisachenko/go-aop-php > > > On Saturday, November 24, 2012 8:18:58 PM UTC+1, Alexander Lissachenko > wrote: >> >> I have developed an Go! AOP library for PHP that can be used with any PHP >> applications and frameworks. It written in plain PHP and doesn't require >> any PHP extensions, doesn't use evals and expensive function calls, doesn't >> require changes in the original source code. There is a good support for >> debugging with XDebug, because auto-generated classes are clean and simple. >> I'm planning to create a bundle for Symfony2 as alternative for >> JMSAopBundle after SymfonyCampUA-2012 where I'll have a talk about this >> library. >> >> Here is a link: https://github.com/lisachenko/go-aop-php >> >> четверг, 30 сентября 2010 г., 21:42:16 UTC+4 пользователь Yuen-Chi Lian >> написал: >>> >>> 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
