Dependencies of aspects is not a task for that library. Dependencies should be done with DIC and I have a success with DIC integration. Just created a service definition for aspect kernel that used factory method to get an instance of aspect kernel. Compiler pass then looks for services with tag 'go.aspect' and just register aspects into the aspect kernel.
понедельник, 3 декабря 2012 г., 17:25:12 UTC+4 пользователь Johannes Schmitt написал: > > 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 > <[email protected]<javascript:> > > 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 [email protected]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
