On 12/3/12 12:00 AM, Marco Pivetta wrote:
@Florin: I'm not sure I understand your rant, but are you implying that
implementing a new feature that opens new ways of implementing base
functionality such as caching and proxying method calls is bad?
AOP solves a bunch of problems by reducing complexity from O(n*m) to
O(n) (see https://github.com/AOP-PHP/AOP/issues/3 ) and you can't simply
ignore that.
It maybe doesn't need to be integrated in the framework, since any
bundle would do anyway, but I don't see a point in trying to stop people
from implementing well known and well working patterns.
It is also unclear why you are pointing to a routing issue to justify
why people want to develop new stuff: shall we all stop and spend our
time fixing current code? Is it not allowed to build new code on new
concepts?
Also, please stop all the ZF2 bitching,
I agree with that.
Sincerely,
Your usually lurking ZF2/D2 dev
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 2 December 2012 22:29, Florin Patan <florinpa...@gmail.com
<mailto:florinpa...@gmail.com>> wrote:
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 <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%2bunsubscr...@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
--
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
