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
