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

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

Reply via email to