On Mon, Jan 7, 2013 at 1:11 AM, Sebastian Krebs <krebs....@gmail.com> wrote:
> 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. > > I've thought about two types of solutions: - The first one is to add another argument that supplies additional characters for the annotation key, so for example getAnnotation("name", "\\/!") Wil match any alphanumericlal values and \, / and !. From the moment it'll catch another tag - it'll be the value. So @var String @param2/param2("bar") Will be array('var' => 'String', 'param2/param2' => '("bar")' ); - The second option, is to built some pre-defined parsing ways, so for example we can define REFLECTION_PARSE_DEFAULT which will parse the annotations just with alphanumerical characters. REFLECTION_PARSE_FUNCTION which will make the parsing of the parameters in the brackets so @ORM(Key="foo") Will be parsed to array( 'ORM' => array( 'key' => "foo" )) and @MaxLength(255) will be parsed to array ('MaxLength' => 255). What do you think? > > > > > > 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 :) > > Sure! :) To tell the truth, I've implemented this parsing, too, in userland for documenting application API's, and including it in PHP can make API (web-services) documentations really easy! > > Regards, > Sebastian > > > > > > What do you think? > > > > > > -- > github.com/KingCrunch >
