On Wed, Feb 18, 2015 at 9:45 PM, Benjamin Eberlei <kont...@beberlei.de> wrote: > > > On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil <pajou...@gmail.com> wrote: >> >> As a Doctrine user, I find this way worse than current state. This >> syntax looks UGLY and contains a lot of useless clutter. And yeah, >> adding named parameters to PHP be pretty helpful to make annotations >> more readable. :( > > > This is in no way related, only by the choice of guilherme's syntax. You > could > pass an array of options to the constructor to simulate named easily.
Sorry, but I find passing an array with fields instead of proper named parameters as a hack, not as a solution. :( >> >> And to what Francois said ("Anyway, I don't like the OO features >> people want to add everywhere. They can get strings and inject them to >> OO, but that's not the role of the annotation layer, IMHO. I >> definitely prefer the KISS approach."). What's exactly wrong with >> doing annotations in an object oriented manner? Both Doctrine >> Annotations and C# have them as objects, and it works well. Having >> annotations as just array of expressions/strings/whatever and needing >> another library to parse them is not really that great "upgrade" from >> current state. :( > > > PHP is not primarily an OOP language. As a user of Doctrine you wouldn't > need to care, > because we would wrap it anyway in our current code. So it wouldn't matter. > I know you could wrap it in your code, but that would still mean there would probably be multiple implementations of Annotations in the "wild", instead of a good complete functionality in the language itself. I know PHP is not primarily an OOP language, but Annotations IMHO make sense as classes, so I don't see any reason why would it be bad to make them in that way. Also, making Annotations be classes won't magically turn PHP into a primarily OOP language? Regards Pavel Kouřil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php