Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
References: <CANVTSm5XE69i=KkZV621+tmwWbSKnsHECN0UsLin7mdBTc+jOg@mail.gmail.com> <45FD2112-5469-48A2-8941-92415EC711E1@strojny.net> <CANVTSm5U-co=opgLXfgwhETBDwp-EKhGKzibgEmt=FCzSpX=vA@mail.gmail.com> <CADyq6sKj5wkZ2ieBHdfzJafcBmdRi7FY_Bohg5HSLWQJmjAooA@mail.gmail.com> <CANVTSm7d_SY=hEohBjw5VVRraJGJ6jSKih3gDZq5uT2S0_=YyQ@mail.gmail.com> <CALtuQzDQP_+NHLKEbX9iOi6L4pbtW4xTJLutH=ibkHUDSR7Z6w@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CALtuQzDQP_+NHLKEbX9iOi6L4pbtW4xTJLutH=ibkHUDSR7Z6w@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <04DB7593-CF49-4F3C-9C28-287B768AC6A7@zerocue.com>
Cc: PHP internals list <internals@lists.php.net>
Date: Sun, 6 Jan 2013 18:12:42 -0600
To: Sebastian Krebs <krebs.seb@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader
From: cpriest@zerocue.com (Clint Priest)



-Clint

On Jan 6, 2013, at 5:11 PM, Sebastian Krebs <krebs.seb@gmail.com> wrote:

> 2013/1/6 Yahav Gindi Bar <g.b.yahav@gmail.com>
>=20
>> On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta <ocramius@gmail.com> wrote=
:
>>=20
>>>=20
>>> I think that our work is to isolate each annotation so it'll be easy to
>>>> access, then, it'll be easy enough to write the code that creates
>> "complex
>>>> annotations", such as constructors and so on, in userland.
>>>=20
>>> In fact, there's probably no need (now) to go on and build a full
>>> annotation reader that instantiates classes and does fancy stuff as we
>>> currently do in doctrine/common.
>>> A fast parser is more than enough I suppose. That's our bottleneck
>>> (besides scanning files).
>>>=20
>>>=20
>>> Marco Pivetta
>>>=20
>>> http://twitter.com/Ocramius
>>>=20
>>> http://ocramius.github.com/
>>=20
>> So the problem is the syntax which is difference?
>> When wrote this RFC, I just though about basic cases...
>>=20
>> Though I agree with you that the main problem is the syntax.
>> We can extract the entire doc-comment and only isolate between annotation=
s,
>> so doc-comment like:
>> /**
>>  * @Route("/")
>>  * @ORM(Key=3D"foo")
>>  * @var string
>> */
>>=20
>> Will be : array( 'Route("/")' =3D> "", 'ORM(Key=3D"foo")' =3D> "", "var" =3D=
>
>> "string" )
>> But the question is it really worth it, since you'll probably need to
>> create some sort of "sub-parser" that uses this isolated annotations arra=
y
>> and apply on them your syntax.
>=20
> As a suggestion, that should cover most (all?) cases: The identifier could=

> be defined as "between @ and the first non-alphanumeric character" (it
> should probably allow some special like "/", or "\" to allow namespace-lik=
e
> annotations). @Route("/") would be array( 'Route' =3D> '("/")'. Now a
> secondary parser only needs to take care about ("/"), but for example it
> can already directly test, whether or not the annotation exists.
>=20
>=20
>>=20
>> That's being said, if we'll see performance improvements, I really think
>> that it's a good solution to start with, since because its not an
>> Attributes, I don't think that we should dictate the syntax for each
>> application. Each application will get the doc-comment annotation and wil=
l
>> be able to apply on it its own syntax and fancy stuff... I think that it'=
s
>> the best solution because of BC too.
>=20
> To throw that in: Multiline-annotations must be taken into account too :)
>=20
>=20
> Regards,
> Sebastian
>=20
>=20
>>=20
>> What do you think?
>=20
>=20
>=20
> --=20
> github.com/KingCrunch