Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50291
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain quepasacorp.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4CE3891E.6030801@dmi.me.uk>
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>
	<4CE3891E.6030801@dmi.me.uk>
Date: Wed, 17 Nov 2010 01:59:19 -0600
Message-ID: <AANLkTikL5wnossDAFGrtSfDXdatJP3GL3o80YKznH0My@mail.gmail.com>
To: Dave Ingram <dave@dmi.me.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0015174c3f4af73b3204953b0cbb
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) supportdiscussion
From: will.fitch@quepasacorp.com (Will Fitch)

--0015174c3f4af73b3204953b0cbb
Content-Type: text/plain; charset=ISO-8859-1

Fair enough. I'm bias towards the C# annotation syntax, so that's my
attraction to it.

On Wed, Nov 17, 2010 at 1:49 AM, Dave Ingram <dave@dmi.me.uk> wrote:

>  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
> >>
> >>
> >
>
>


-- 

Thanks,

Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch

--0015174c3f4af73b3204953b0cbb--