2013/1/6 Yahav Gindi Bar <g.b.ya...@gmail.com>
> On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta <ocram...@gmail.com> wrote:
>
> >
> > 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.
> >>
> >
> > 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).
> >
> >
> > Marco Pivetta
> >
> > http://twitter.com/Ocramius
> >
> > http://ocramius.github.com/
> >
>
> So the problem is the syntax which is difference?
> When wrote this RFC, I just though about basic cases...
>
> Though I agree with you that the main problem is the syntax.
> We can extract the entire doc-comment and only isolate between annotations,
> so doc-comment like:
> /**
> * @Route("/")
> * @ORM(Key="foo")
> * @var string
> */
>
> Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
> "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 array
> and apply on them your syntax.
>
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-like
annotations). @Route("/") would be array( 'Route' => '("/")'. Now a
secondary parser only needs to take care about ("/"), but for example it
can already directly test, whether or not the annotation exists.
>
> 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 will
> be able to apply on it its own syntax and fancy stuff... I think that it's
> the best solution because of BC too.
>
To throw that in: Multiline-annotations must be taken into account too :)
Regards,
Sebastian
>
> What do you think?
>
--
github.com/KingCrunch
