Florin,
What a nice rant !
But as for most rant, only a few lines of you message is relevant
(the other having been treated in previous message or being
non-argument) let me handle them:
- "comments": annotation is one way to configure AOP, use
php/xml/yml if you like,
- "writing events instead of comments":
- you can use AOP with 3rd party libs that do not use events
- you won't have the overhead of dispatching an event if no
listeners is attached to the events (ie you can logging in your
debug environment that has 0 impact in your prod env).
As I state in my second message, my intention is more to promote
AOP than to have something in Symfony. You seem to be this kind of
people that have problems with (not so) new concepts, you can go
read me first message again then !
The only part of your message I like is "I'll change my mind".
For #2679, I don't really see how it relates with AOP nor why it
is a bug - As a reminder the issue state that
http://admin-zone/<any url> should return a 403 even if <any url>
does not correspond to an existing route. It currently returns a
404 if the route does not exist. This is because the routing is
now triggered before the security, for good reasons.
Cheers,
Victor
Le dimanche 2 décembre 2012 22:29:55 UTC+1, Florin Patan a écrit :
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
<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
<http://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
<mailto:symfony-devs@googlegroups.com>
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
<mailto:symfony-devs+unsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
