Hey Alexander, thanks for your kind remarks :)
I'd be curious to learn how you handle dependencies of aspects. Do you allow some kind of dependency injection for them? Cheers, Johannes On Mon, Dec 3, 2012 at 2:10 PM, Alexander Lissachenko < lisachenko...@gmail.com> wrote: > 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<https://github.com/symfony/symfony/issues/6139> >> [2] >> https://github.com/symfony/**symfony/pull/3296<https://github.com/symfony/symfony/pull/3296>in >> some extends >> [3] http://en.wikipedia.org/wiki/**Aspect-oriented_programming#** >> Terminology<http://en.wikipedia.org/wiki/Aspect-oriented_programming#Terminology> >> [4] https://github.com/symfony/**symfony/issues/6139#** >> issuecomment-10841221<https://github.com/symfony/symfony/issues/6139#issuecomment-10841221> >> [5] >> https://github.com/symfony/**symfony-standard<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<https://picasaweb.google.com/victor.berchet/Sf2?authkey=Gv1sRgCM7A8tqJoc_zywE#slideshow/5816753838641482210> >> [9] http://symfony.com/doc/**current/components/event_** >> dispatcher/introduction.html<http://symfony.com/doc/current/components/event_dispatcher/introduction.html> >> [10] https://secure.gravatar.com/**avatar/** >> e7af3ef8e48a800cd2eedae073104c**1a?s=400&d=https://a248.e.** >> akamai.net/assets.github.com%**2Fimages%2Fgravatars%** >> 2Fgravatar-user-420.png<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<http://jmsyst.com/bundles/JMSAopBundle#overview> >> [12] http://www.eclipse.org/**aspectj/ <http://www.eclipse.org/aspectj/> >> [13] >> http://demo.qooxdoo.org/**current/apiviewer/#qx.core.**Aspect<http://demo.qooxdoo.org/current/apiviewer/#qx.core.Aspect> >> [14] http://en.wikipedia.org/wiki/**Aspect-oriented_programming#** >> Implementations<http://en.wikipedia.org/wiki/Aspect-oriented_programming#Implementations> >> [15] >> https://twitter.com/**robertlemke/status/**274532529975984128<https://twitter.com/robertlemke/status/274532529975984128> >> [16] https://github.com/AOP-PHP/AOP >> [17] >> https://twitter.com/**julienPauli/status/**274180211132755968<https://twitter.com/julienPauli/status/274180211132755968> >> [18] >> https://github.com/schmittjoh/**JMSAopBundle<https://github.com/schmittjoh/JMSAopBundle> >> [19] >> https://github.com/lisachenko/**go-aop-php<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<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 > -- 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
