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

Reply via email to