Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50289
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain dmi.me.uk designates 77.68.52.130 as permitted sender)
Message-ID: <4CE3891E.6030801@dmi.me.uk>
Date: Wed, 17 Nov 2010 07:49:50 +0000
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Will Fitch <will.fitch@quepasacorp.com>
CC: PHP Internals <internals@lists.php.net>
References: <AANLkTik703Bky+ZtjdzBMY8tr97m34jDSSMyoB9opJKR@mail.gmail.com>	<4CE3340F.6090304@sugarcrm.com>	<87.0F.25421.F4933EC4@pb1.pair.com>	<4CE339DF.1020605@sugarcrm.com>	<AANLkTi=fRYk=GFv5LxDQ0_RTbjpuuwth2GYpbjqRNKfP@mail.gmail.com>	<4CE33D54.8000009@sugarcrm.com>	<AANLkTinPw2CKSrC9HW-E4h7P8Lug46wq4HrNYR+8S8AU@mail.gmail.com>	<4CE33F06.3080507@gmail.com>	<AANLkTi=2WMTK3p=gt9L+xQu3JH0zcEcRNC4E2orw-sCr@mail.gmail.com>	<4CE34E1B.20001@gmail.com> <AANLkTimonQW+__4bswgpNr79TKWv+vA-dRRZx9BoePQ2@mail.gmail.com>
In-Reply-To: <AANLkTimonQW+__4bswgpNr79TKWv+vA-dRRZx9BoePQ2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion
From: dave@dmi.me.uk (Dave Ingram)

 On 17/11/10 06:38, Will Fitch wrote:
> I like the idea, Alec.
>
> My only question is, syntactically, what difference would using a keyword,
> in this case "attribute", as opposed to brackets "[]"?
I would say that it provides better searchability -- it's easier for
people new to the feature to recognise what it means, and to search for
how to use it. I for one didn't understand what []-style annotations
were when I first saw them, and had no idea how to find out what it meant.


D


> On Tue, Nov 16, 2010 at 9:38 PM, Alec Gorge <alecgorge@gmail.com> wrote:
>
>> Ah, thanks.
>>
>> This is my proposed syntax and examples of it being used:
>> https://gist.github.com/702925
>>
>> Here is my answer to those questions:
>>
>> - PHP code
>> - See the gist for syntax
>> - Return object instances of the annotation because then you can call
>> methods on the annotation if you need to (it think it would be useful)
>> - Can you APC cache ones that exist at compile time and then not cache ones
>> that are created at runtime (since they are likely to change anyways,
>> request to request)?
>> - Method argument order to maintain consistency with PHP syntax. Named
>> arguments if PHP ever gets 'em. The grammar addition should use the grammar
>> already there in the grammar file for calling methods so that it always
>> works with the new way of calling methods and functions.
>> - Yes for inherited metadata as long as you can filter it out (exactly like
>> in the RFC).
>>
>> A another comment:
>>
>> getAnnotation($name) and getAnnotation($name, $type) both have to become
>> getAnnotations and then always return an array. This makes things more
>> consistent and allows for multiple metadata structures for each method.
>>
>> The gist I posted would be a fully working API (albeit very basic with no
>> proper error/exception handling) if the url parsing code was put in, but I
>> left it out for brevity.
>>
>> Opinions?
>>
>> -Alec
>>
>>
>>
>>
>> On 11/16/2010 9:39 PM, guilhermeblanco@gmail.com wrote:
>>
>>> Hi Alec,
>>>
>>> Here is the quick list:
>>> - Where to put the metadata information? docblock or though php code?
>>> - Syntax (based on first decision)
>>> - Return would be an array or object instances
>>> - Compile time or run time (decision is more about APC being able to
>>> cache, but instances being created at runtime automatically or no APC
>>> cache but instances only being created when requested (during
>>> Reflection call)
>>> - Named variables for instantiation or method arguments order? How
>>> would we deal with the need of Reflector during constructor if second
>>> sounds better?
>>> - Would we support inherited metadata?
>>>
>>> Cheers,
>>>
>>> On Wed, Nov 17, 2010 at 12:33 AM, Alec Gorge<alecgorge@gmail.com>  wrote:
>>>
>>>> In my opinion (as a person with 0 karma), I think that sounds reasonable
>>>> because most people are most concerned about the actual implementation
>>>> (syntax, performance, apc etc) because I don't think many argue that
>>>> Metadata doesn't have value.
>>>>
>>>> What are the 5 different discussion topics you are thinking of, just out
>>>> of
>>>> curiosity?
>>>>
>>>> Also, I can just post my syntax idea as a gist or pastie or something
>>>> instead of making an rfc...
>>>>
>>>> -Alec
>>>>
>>>> On 11/16/2010 9:29 PM, guilhermeblanco@gmail.com wrote:
>>>>
>>>>> Hi Stas,
>>>>>
>>>>> Ok, so you think I should just consider everyone want some sort of
>>>>> meta attribute support and start discussing the topics?
>>>>> Should I separate it in different threads or put it all here?
>>>>>
>>>>> The subject is big and I identify at least 5 different discussions
>>>>> that can diverge.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshev<smalyshev@sugarcrm.com>
>>>>>  wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>>  I'm able to write 10 RFC's, but none will care until we reach this
>>>>>>> list with a patch.
>>>>>>>
>>>>>> Not entirely true. Patch helps, but with feature this big and complex
>>>>>> having
>>>>>> consensus on design before actually implementing it may be better and
>>>>>> save
>>>>>> you some time.
>>>>>> As for polls, I think generic "having annotations" poll is not very
>>>>>> useful.
>>>>>> It's like having a poll "should we have cool features in PHP?" Of
>>>>>> course
>>>>>> we
>>>>>> should! The devil is in the details. And so far the details of this
>>>>>> thing
>>>>>> contain a significant number of devils we have to handle.
>>>>>> --
>>>>>> Stanislav Malyshev, Software Architect
>>>>>> SugarCRM: http://www.sugarcrm.com/
>>>>>> (408)454-6900 ext. 227
>>>>>>
>>>>>>
>>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>