I understand where you're coming from, and I appreciate the effort
you've put into this RFC so far, but what I meant is that (although I
don't have karma and won't be voting), *if* I were to vote, I would
only +1 annotations if they were extremely limited (key=>value pairs).
That's why implementation matters to me - I see the benefit of simple
meta-data retrieval but not an extensive syntax addition to the
language.
I also think that's why you see people suggesting docblock, because
what it already offers is similar to this key=>value metadata
retrieval using the @tag syntax. Really, people are saying they favor
some meta-data retrieval but not the complicated annotations that you
want.
This is why I think you cannot have a vote on annotations in general.
On Tue, Nov 16, 2010 at 9:47 AM, guilhermebla...@gmail.com
<guilhermebla...@gmail.com> wrote:
> @Chad: You're getting me wrong here.
>
> If results of poll decide for OK to meta attribute support, next poll
> would be which implementation to choose.
> I can find 3 different implementations that we can choose, but anyone
> is free to contribute.
>
> - Docblock
>
> /** @Foo */
> class User { ... }
>
> - New syntax similar to first patch
>
> [Foo]
> class User { ... }
>
> - A keyword scope similar to method/namespace declaration
>
> annotate { return new Foo(); }
> class User { ... }
>
> But before even spend time talking over and over about implementation,
> I wanna ask if we should invest time into it, since I got a lot of
> flaming responses (and I still continue, even though people barely see
> what I'm asking).
>
> If you say that we should enhance docblock to allow retrieve of @foo,
> you're automatically saying +1 to this thread.
> I do not want to enter in discussion about implementation because I
> don't even know if it will be accepted. I don't want to spend a lot of
> time to produce a patch to something that will not be accepted. So
> let's decide IF and possibly WHAT to implement, then I can work on it.
>
> All I want is a democratic decision, and not something that one guy
> answer as "NO" and end of story.
> If majority says "YES", one person being against it doesn't sound to
> me like a democracy/meritocracy.
>
>
> Cheers,
>
> On Tue, Nov 16, 2010 at 3:37 PM, Chad Fulton <chadful...@gmail.com> wrote:
>> On Tue, Nov 16, 2010 at 6:03 AM, Lars Schultz <lars.schu...@toolpark.com>
>> wrote:
>>> Hi,
>>>
>>> I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
>>> but simply I can't believe that you're talking about this, again.
>>>
>>> I think Annotation-Supporters have made their point, but shouldn't they let
>>> the PHP 5.4 Developers get on with it and let them roll out a new version
>>> instead of forcing them to reply to lengthy emails about the same topic over
>>> and over again. One could almost believe that you're hoping to drown their
>>> voices by frustrating them into not replying anymore, therefore winning your
>>> vote.
>>>
>>> cheers.
>>> Lars
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> ^ I agree.
>>
>> ----
>>
>> I also don't think you can discuss annotations without simultaneously
>> discussing their implementation. To me, it looks like you're trying to
>> force through a vote on a very vague topic "should PHP support
>> Annotations", and then use that vote later to force through an
>> implementation that many core people have already said is not
>> desirable.
>>
>> Many of the arguments that are central to the question of "should PHP
>> support Annotations" MUST deal with their implementation because they
>> add a large new set of syntax to the language.
>>
>> I doubt anyone would support annotations "at any cost", and yet that's
>> the vote you're trying to force here.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
> Guilherme Blanco
> Mobile: +55 (16) 9215-8480
> MSN: guilhermebla...@hotmail.com
> São Paulo - SP/Brazil
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
