I like the idea, Alec. My only question is, syntactically, what difference would using a keyword, in this case "attribute", as opposed to brackets "[]"?
On Tue, Nov 16, 2010 at 9:38 PM, Alec Gorge <alecgo...@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, guilhermebla...@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<alecgo...@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, guilhermebla...@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<smalys...@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 > > -- Thanks, Will Fitch Director of Operations | Quepasa.com 931.205.8242 | will.fi...@quepasacorp.com Twitter: twitter.com/willfitch
