# Native Annotation Syntax - Thread: https://externals.io/message/89382 - Original archive: https://news-web.php.net/php.internals/89382 - Started by Pedro Cordeiro on 2015-11-24T16:30:41+00:00 - Messages: 42 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/89382.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #89382 — Pedro Cordeiro — 2015-11-24T16:30:41+00:00 URL: https://externals.io/message/89382#89382 Hello. I'd been reading some old RFCs recently, and I found two RFCs on the subject of annotations, both by Guilherme Blanco. The first one, which proposed a native syntax for annotations, is marked as 'declined', and I couldn't find a discussion for it anywhere. The second one, which proposes retrieving annotation from DocBlocks through reflection is 'inactive', with no further explanation. I'd really like to see native annotation support for PHP that doesn't live in comments. Is there a reason those RFCs were dropped, or was it just lack of interest? - Pedro. --- ## #89384 — Benjamin Eberlei — 2015-11-24T16:40:04+00:00 URL: https://externals.io/message/89382#89384 · In reply to: #89382 On Tue, Nov 24, 2015 at 5:30 PM, Pedro Cordeiro wrote: > Hello. > > I'd been reading some old RFCs recently, and I found two RFCs on the > subject of annotations, both by Guilherme Blanco. The first one, which > proposed a native syntax for annotations, is marked as 'declined', and I > couldn't find a discussion for it anywhere. The second one, which proposes > retrieving annotation from DocBlocks through reflection is 'inactive', with > no further explanation. > > I'd really like to see native annotation support for PHP that doesn't live > in comments. > > Is there a reason those RFCs were dropped, or was it just lack of interest? > There was a vote on the declined one from Guilherme, which was in the old mailing list style, you'd have to search the mailing ilst archives to find the thread with the discussion and voting. > > - Pedro. --- ## #89393 — Rowan Collins — 2015-11-24T19:05:58+00:00 URL: https://externals.io/message/89382#89393 · In reply to: #89382 > I'd been reading some old RFCs recently, and I found two RFCs on the > subject of annotations, both by Guilherme Blanco. The first one, which > proposed a native syntax for annotations, is marked as 'declined', and I > couldn't find a discussion for it anywhere. The second one, which proposes > retrieving annotation from DocBlocks through reflection is 'inactive', with > no further explanation. > > I'd really like to see native annotation support for PHP that doesn't live > in comments. > > Is there a reason those RFCs were dropped, or was it just lack of interest? I think one of the stumbling blocks in recent discussions of annotation support is just how much support should be provided; off the top of my head, this could be: - a few extra functions in reflection classes to parse the items within a docblock (docblocks are already handled in reflection separately from normal comments) - automatic instantiation of a set of standard Annotation objects with the text content above - automatic instantiation of classes based on the annotations provided - built-in support for applying annotations to the objects they appear on, perhaps in the form of full Aspect-Oriented Programming support At first sight, these seem like details which could be tweaked later, but they make a difference to what syntax to standardise: is the annotation name just a string, or a valid class name? is the value of the annotation just a string, or a parseable PHP expression? is it more useful to use the de facto existing syntax in DocBlocks, or to add a new keyword or operator? etc The devil, as ever, is in the detail. Regards, -- Rowan Collins [IMSoP] --- ## #89397 — Sara Golemon — 2015-11-25T00:31:51+00:00 URL: https://externals.io/message/89382#89397 · In reply to: #89393 > At first sight, these seem like details which could be tweaked later, but > they make a difference to what syntax to standardise: is the annotation name > just a string, or a valid class name? is the value of the annotation just a > string, or a parseable PHP expression? is it more useful to use the de facto > existing syntax in DocBlocks, or to add a new keyword or operator? etc > If we're going to use something in the docblock, then I wouldn't want it parsed on compilation, but rather have it be an on-demand parse while reflecting. The reason being that there are plenty of docblock'd PHP libraries out there using invalid annotations because they're not running it through tools to tell them what they got wrong. Waiting till they've actually tried to examine it through reflection lets us throw an exception on code that cares about it rather than preventing code which ignores reflection from running. I, for one, am a fan of Java style annotations which allow a string name plus optional metadata. @@foo class Bar { @@Baz("something", 123, [ 'a', 'b', ''c']) public function qux() { ... } } Though the formality of having to define the annotation as an interface is a bit overkill for PHP, the same rules Hack uses would be clear and simple enough: <> class Bar { <> public function qux() { ... } } And no, I'm not picky about the parser symbol used... In fact, allowing an optional '//' prefix to annotations might be nice for compatibility. -Sara --- ## #89403 — Pedro Cordeiro — 2015-11-25T11:04:32+00:00 URL: https://externals.io/message/89382#89403 · In reply to: #89397 I'd really like to see something outside the docblock. Comment annotations are a workaround for the lack of native annotations. It makes the environment hard to learn ("What does @param do? And what does @ManyToMany do?"), it makes it impossible for IDEs to hint/autocomplete without project-specific plugins, and adds this odd notion that removing some comment blocks might break an app (which is just awful). @beberlei, I had searched through the archives already and couldn't find the vote. I found the discussion (in which many people advocated for docblock annotations), but didn't find the vote. I feel like this is a major feature that's missing, and people are using it in a suboptimal way (docblocks), so I thought I'd reopen the discussion and see if someone more familiar with the internals feels like implementing it (I don't feel confident enough since I've never tried messing with into the internals). 2015-11-24 22:31 GMT-02:00 Sara Golemon : > On Tue, Nov 24, 2015 at 11:05 AM, Rowan Collins > wrote: > > […] > name > > […] > just a > > […] > facto > > […] > If we're going to use something in the docblock, then I wouldn't want > it parsed on compilation, but rather have it be an on-demand parse > while reflecting. The reason being that there are plenty of > docblock'd PHP libraries out there using invalid annotations because > they're not running it through tools to tell them what they got wrong. > Waiting till they've actually tried to examine it through reflection > lets us throw an exception on code that cares about it rather than > preventing code which ignores reflection from running. > > I, for one, am a fan of Java style annotations which allow a string > name plus optional metadata. > > @@foo > class Bar { > @@Baz("something", 123, [ 'a', 'b', ''c']) > public function qux() { ... } > } > > Though the formality of having to define the annotation as an > interface is a bit overkill for PHP, the same rules Hack uses would be > clear and simple enough: > > <> > class Bar { > <> > public function qux() { ... } > } > > And no, I'm not picky about the parser symbol used... In fact, > allowing an optional '//' prefix to annotations might be nice for > compatibility. > > -Sara --- ## #89409 — Lester Caine — 2015-11-25T15:47:54+00:00 URL: https://externals.io/message/89382#89409 · In reply to: #89403 > I feel like this is a major feature that's missing, and people are using it > in a suboptimal way (docblocks), so I thought I'd reopen the discussion and > see if someone more familiar with the internals feels like implementing it In previous discussions it was pointed out that a substantial amount of legacy code already uses docblock style annotation, and that is well supported by IDE's and other tools, so there is no reason not it continue to support that substantial base. Any new system would require every third party tool to be adapted to use it was there any reason to load the code base with something which will only have a limited uptake. Adding an extension to provide an alternative would be the correct way forward, and then if that gains traction, look to it's status then. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89410 — Pedro Cordeiro — 2015-11-25T16:31:28+00:00 URL: https://externals.io/message/89382#89410 · In reply to: #89409 2015-11-25 13:47 GMT-02:00 Lester Caine : > Any new system would require > every third party tool to be adapted to use it > That's not true at all. A new syntax would in no way invalidate parsing annotations from docblocks. The only legacy code that is supported by IDEs (if they are, PHPStorm will not hint/autocomplete, nor will eclipse/netbeans) would be Symfony2/Doctrine2. There are tons of other tools that with custom annotations (JMSSerializer as an example) that do not have any support at all. This argument is so flawed that you didn't consider that there are many parsers with many different syntaxes ( https://github.com/jan-swiecki/php-simple-annotations, https://github.com/nette/neon) and that ANY implementation, be it through docblocks or with a native syntax would require a rewrite anyway for many projects if those tools want to support the new native feature. Also, doing it through an extension is a nice way to delay adoption, because shared hosts rarely give the option to install new extensions. I don't have a vote here, but if I had, I'd strongly oppose any docblock-based implementation. --- ## #89411 — Larry Garfield — 2015-11-25T16:42:12+00:00 URL: https://externals.io/message/89382#89411 · In reply to: #89410 > 2015-11-25 13:47 GMT-02:00 Lester Caine : > > > […] > That's not true at all. A new syntax would in no way invalidate parsing > annotations from docblocks. > > The only legacy code that is supported by IDEs (if they are, PHPStorm will > not hint/autocomplete, nor will eclipse/netbeans) would be > Symfony2/Doctrine2. There are tons of other tools that with custom > annotations (JMSSerializer as an example) that do not have any support at > all. > > This argument is so flawed that you didn't consider that there are many > parsers with many different syntaxes ( > https://github.com/jan-swiecki/php-simple-annotations, > https://github.com/nette/neon) and that ANY implementation, be it through > docblocks or with a native syntax would require a rewrite anyway for many > projects if those tools want to support the new native feature. > > Also, doing it through an extension is a nice way to delay adoption, > because shared hosts rarely give the option to install new extensions. > > I don't have a vote here, but if I had, I'd strongly oppose any > docblock-based implementation. When Drupal adopted annotations, the absolute #1 objection people had was "but docblocks aren't code, you moron!" There's no value in language-native annotations being in the docblock, other than BC with *some* existing implementations. However, doing so would make static checking more difficult; If annotations become a language-native feature, they should be a first-class citizen to make it easier for IDEs to handle. I'm also not super picky on what the tokens are, however I do think mapping them to actual classes, like Doctrine does, would be the most flexible. Structured data all the things. That also means annotations can be namespaced, be affected by use statements, and so forth. In a sense, they become isomorphic to: class Foo { public static function getAnnotations() { return [ new OneToMany('a', 'b', 'c'), new Stuff('d', 4); ]; } } Except they can be applied to anything reflectable rather than just classes. (Functions, methods, classes, object properties.) Sara's suggestion of making them legal within a // comment line for BC reasons is interesting, but we don't do that for any other new syntax AFAIK. Plus, it means it's harder to comment out an annotation temporarily for debugging. There's still /* */, but it's one more quirk to have to think about. -- --Larry Garfield --- ## #89412 — Rowan Collins — 2015-11-25T16:47:26+00:00 URL: https://externals.io/message/89382#89412 · In reply to: #89411 Larry Garfield wrote on 25/11/2015 16:42: > However, doing so would make static checking more difficult; If > annotations become a language-native feature, they should be a > first-class citizen to make it easier for IDEs to handle. Could you explain why docblocks are harder to parse than text outside docblocks? As far as I know, IDEs *already* parse docblocks, e.g. using @param and @return for type analysis, so I don't really see why generalising that would be a big problem. --- ## #89413 — Pedro Cordeiro — 2015-11-25T16:53:18+00:00 URL: https://externals.io/message/89382#89413 · In reply to: #89412 Rowan, even if they are not harder, there is no reason to keep this feature in docblocks. Even the argument "compatibility with current implementations" is flawed, because there are many different implementations (not only doctrine's) with different syntaxes, so any native option would break SOME implementations. Docblocks are Documentation Blocks, which is meant for documentation only. Mixing documentation (@param) with runtime stuff (@manyToMany) is counter-intuitive and makes the ecosystem harder to learn. It's also weird that removing comment blocks break an app. 2015-11-25 14:47 GMT-02:00 Rowan Collins : > Larry Garfield wrote on 25/11/2015 16:42: > > > […] > > Could you explain why docblocks are harder to parse than text outside > docblocks? As far as I know, IDEs *already* parse docblocks, e.g. using > @param and @return for type analysis, so I don't really see why > generalising that would be a big problem. --- ## #89414 — Rowan Collins — 2015-11-25T16:53:36+00:00 URL: https://externals.io/message/89382#89414 · In reply to: #89403 Pedro Cordeiro wrote on 25/11/2015 11:04: > I'd really like to see something outside the docblock. Comment > annotations are a workaround for the lack of native annotations. This is true, but they are now a very widely used workaround, and any native support for them could be polyfilled using the kind of userland libraries that already exist. > It makes the environment hard to learn ("What does @param do? And what > does @ManyToMany do?") I'm not sure how this is made any easier by moving the annotations out of the docblock. I suppose it's a little confusing that, within the docblock, code annotations and documentation annotations share the same syntax; maybe we could use a different prefix, like "@@" instead of "@"? This would also give a chance for projects to transition to the new standard syntax, rather than having to break compatibility if their old implementation doesn't quite match. > it makes it impossible for IDEs to hint/autocomplete without > project-specific plugins That's a good argument for standardisation, but doesn't require moving out of the docblock; in fact, it doesn't even require any action from this list, as PHP-FIG could simply agree a PSR, and IDEs like PHPStorm would use that as an implementation guide. > and adds this odd notion that removing some comment blocks might break > an app (which is just awful). If it helps, just think of /** ... */ as not being a comment, but already a first-class piece of syntax. Note that the parser already thinks so - hence we can have functions like ReflectionMethod::getDocComment. IDEs also parse docblocks already, and most syntax highlighting editors can probably style them differently from comments so that you don't delete them by mistake. Now, if annotations were being implemented as something brand new to PHP, like say Traits were, I'd agree that we should look to languages like Java and C# for syntax ideas. But since a lot of people have already invented annotations using docblocks, and since docblocks are already supported by the reflection classes, I'm not convinced of why we shouldn't just carry on down that route. Regards, -- Rowan Collins [IMSoP] --- ## #89415 — Rowan Collins — 2015-11-25T17:00:47+00:00 URL: https://externals.io/message/89382#89415 · In reply to: #89413 Pedro Cordeiro wrote on 25/11/2015 16:53: > Rowan, even if they are not harder, there is no reason to keep this > feature in docblocks. Well, I can think of one reason: backwards compatibility. I don't mean with current frameworks - as you say, these are not currently standardised, so some will need to be adapted whatever is implemented in core - but with older versions of PHP. If we invent new syntax, then any code using that feature must *require* the version of PHP that introduces that syntax, because previous versions will simply throw a syntax error. There are a few ways around this, such as: - allowing the annotation to be preceded by // as Sara suggested (or maybe #, to make it look like a C pre-processor directive) - using some other syntax that is currently a no-op, like ECMAScript's wacky "use strict" But ultimately, these end up having the same disadvantages you're claiming for docblocks - they look like things you can delete, or which has some other purpose, but are actually vital to the operation of the code.# I don't feel that strongly in favour of docblocks, but I don't think the reasons given against are particularly strong. Regards, -- Rowan Collins [IMSoP] --- ## #89416 — Lester Caine — 2015-11-25T17:03:17+00:00 URL: https://externals.io/message/89382#89416 · In reply to: #89414 > Now, if annotations were being implemented as something brand new to > PHP, like say Traits were, I'd agree that we should look to languages > like Java and C# for syntax ideas. But since a lot of people have > already invented annotations using docblocks, and since docblocks are > already supported by the reflection classes, I'm not convinced of why we > shouldn't just carry on down that route. Thanks Rowan ... that just about sums it up better than I did ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #89417 — Larry Garfield — 2015-11-25T17:06:57+00:00 URL: https://externals.io/message/89382#89417 · In reply to: #89412 > Larry Garfield wrote on 25/11/2015 16:42: > > […] > > Could you explain why docblocks are harder to parse than text outside > docblocks? As far as I know, IDEs *already* parse docblocks, e.g. > using @param and @return for type analysis, so I don't really see why > generalising that would be a big problem. Not being an IDE author I cannot say for certain, so perhaps it's easier than I imagine. However, speaking as a user I would want a robust level of static syntax validation of my annotations. Having robust syntax validation show up in *some* parts of my docblock but not others is confusing for me as a user; I hypothesize that it would similarly be more difficult to selectively treat bits and pieces of the docblock as code but not others. (My current IDE, PHPStorm, parses a docblock to validate that it matches the method signature but all it does is tell me if the whole thing is valid or not, and if I'm using a "used" class name. It's actually very unhelpful when dealing with complex Doctrine annotations like Drupal uses.) Too, it means that a given annotation directive may have spurious * characters inside its string, if it's multi-line. Sure, that can be filtered out (Doctrine already does), but that's one more complication to have to consider. For me, the "sometimes it's code and sometimes it's not, even though it looks the same" argument is sufficient to reject docblocks as a location for annotations. -- --Larry Garfield --- ## #89418 — Rowan Collins — 2015-11-25T17:10:47+00:00 URL: https://externals.io/message/89382#89418 Pedro Cordeiro wrote on 25/11/2015 17:04: > > 2015-11-25 14:53 GMT-02:00 Rowan Collins >: > > If it helps, just think of /** ... */ as not being a comment, but > already a first-class piece of syntax. > > > Except that it won't parse some stuff while parsing some other stuff. > There was a topic on reddit some time ago with a rant I wrote about > it, and the community seemed to support the notion that comment > annotations are bad: > https://www.reddit.com/r/PHP/comments/1ztstd/rant_it_baffles_me_that_people_think_using/ A very quick response to that rant: > 1) Some php bytecode compilers (for example, facebook's hiphop) will strip your comments. STRIPPING COMMENTS SHOULD NEVER BREAK YOUR APP. So, let's make sure we treat these as first-class entities not comments, and mention it in the language standard (drafted by Facebook, so that they can make HHVM maximally conformant) that these MUST NOT be stripped by compilers or pre-processors. > 2) No IDE hints, no IDE syntax checking because, you know, THEY ARE COMMENTS. If you think I should download a specific IDE plugin to work with Doctrine and another one to work with Symfony and yet another one to work in your specific project with your custom annotations, you can go F@#$ yourself. Total strawman: IDEs parse all sorts of information out of docblocks. They may not parse annotations *because they're not standardised*, but if there were a PSR defining them, I bet the plugin for parsing that syntax would soon be bundled with any IDE with decent PHP support. > 3) Coupling, separation of concerns, encapsulation: having @Route("/something") in a controller class is AWFUL. This appears to be a rant about annotations in general, not the syntax used for them. > 4) Dude, what does "@ManyToMany" do? Oh, ok, and what does "@param" do...? HOW THE HELL AM I SUPPOSED TO TELL SOMEONE "oh, this part over here is metadata, but this one is just a comment"? How do I distinguish between the two of them? Well, no, they're both metadata, just with different targets - @param is targeted at IDEs and documentation generators, @ManyToMany is targeted at a run-time hook, or maybe a code-generation one, or, well, anything that wants metadata about something. I'll stop there, because you probably already had this discussion at the time, but since you linked... Regards, -- Rowan Collins [IMSoP] --- ## #89419 — Rowan Collins — 2015-11-25T17:12:16+00:00 URL: https://externals.io/message/89382#89419 · In reply to: #89417 Larry Garfield wrote on 25/11/2015 17:06: > Too, it means that a given annotation directive may have spurious * > characters inside its string, if it's multi-line. Sure, that can be > filtered out (Doctrine already does), but that's one more complication > to have to consider. I would expect that behaviour would be part of the standard definition, and the core implementation, so don't really see it as a big deal. The same thing happens with leading whitespace in many syntaxes anyway. --- ## #89420 — Rowan Collins — 2015-11-25T17:14:08+00:00 URL: https://externals.io/message/89382#89420 · In reply to: #89417 Larry Garfield wrote on 25/11/2015 17:06: > For me, the "sometimes it's code and sometimes it's not, even though > it looks the same" argument is sufficient to reject docblocks as a > location for annotations. Annotations aren't code, they're metadata, and docblocks already contain metadata; it's just that originally, that metadata was targeted at generating documentation, rather than generating code, or affecting run-time behaviour. --- ## #89421 — guilhermeblanco@gmail.com — 2015-11-25T17:34:05+00:00 URL: https://externals.io/message/89382#89421 · In reply to: #89415 Hi, I'm the co-author of RFC of Annotations, co-author of Annotations in docblock which I abandoned for being conceptually wrong and co-author of Doctrine Annotations. Comments such as the one from Lester Caine "In previous discussions it was pointed out that a substantial amount of legacy code already uses docblock style annotation, and that is well supported by IDE's and other tools, so there is no reason not it continue to support that substantial base." makes me very sad, specially because these claimed legacy code using docblocks were only written that way in first place because Annotations RFC got "declined". Yes, I quoted because it actually acquired a lot of positive votes (over 50% of overall voters) even when there was no 2/3, 50% +1, etc criteria, but that's the feedback I received after bothering a lot of people about patch's resolution: the majority of long period contributors of PHP voted against the patch considering it was too complex, with several modifications to Zend Engine, which lead them to reject as it was. I also got suggested to implement this support outside of core through a PECL extension parsing docblock annotations. If ever any "long term contributor" decided to discuss about potentially introducing Annotations into PHP core, I'll be the first one to help. Until them, anything userland guys ask here IMHO is irrelevant. Regards, On Wed, Nov 25, 2015 at 12:00 PM, Rowan Collins wrote: > Pedro Cordeiro wrote on 25/11/2015 16:53: > > > […] > > Well, I can think of one reason: backwards compatibility. I don't mean > with current frameworks - as you say, these are not currently standardised, > so some will need to be adapted whatever is implemented in core - but with > older versions of PHP. > > If we invent new syntax, then any code using that feature must *require* > the version of PHP that introduces that syntax, because previous versions > will simply throw a syntax error. There are a few ways around this, such as: > > - allowing the annotation to be preceded by // as Sara suggested (or maybe > #, to make it look like a C pre-processor directive) > - using some other syntax that is currently a no-op, like ECMAScript's > wacky "use strict" > > But ultimately, these end up having the same disadvantages you're claiming > for docblocks - they look like things you can delete, or which has some > other purpose, but are actually vital to the operation of the code.# > > I don't feel that strongly in favour of docblocks, but I don't think the > reasons given against are particularly strong. > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > > > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #89422 — Larry Garfield — 2015-11-25T17:39:23+00:00 URL: https://externals.io/message/89382#89422 · In reply to: #89415 > I don't feel that strongly in favour of docblocks, but I don't think > the reasons given against are particularly strong. > > Regards, If you don't feel strongly in favor of them, why are you trying to make a case for them so strongly? Just for kicks? We don't need a "devil's advocate" at this point in the discussion... -- --Larry Garfield --- ## #89423 — Rowan Collins — 2015-11-25T17:48:44+00:00 URL: https://externals.io/message/89382#89423 · In reply to: #89422 Larry Garfield wrote on 25/11/2015 17:39: > > > […] > > If you don't feel strongly in favor of them, why are you trying to > make a case for them so strongly? Just for kicks? We don't need a > "devil's advocate" at this point in the discussion... > Hi Larry, I don't *feel* strongly in favour or against them, but can see advantages and disadvantages on both sides. Feeling strongly is not the same as having a strong argument for your point of view, so just because some people have expressed strong opinions against, I don't see why I shouldn't challenge their reasoning, even if that does mean playing devil's advocate. Which is better: basing the decision on the gut feeling of a handful of people who happen to be here now, or basing it on sound reasoning after thinking through the implications? Regards, -- Rowan Collins [IMSoP] --- ## #89424 — guilhermeblanco@gmail.com — 2015-11-25T17:58:48+00:00 URL: https://externals.io/message/89382#89424 · In reply to: #89423 I can give you a good argument. opcache.save_comments=0 Make it work. On Wed, Nov 25, 2015 at 12:48 PM, Rowan Collins wrote: > Larry Garfield wrote on 25/11/2015 17:39: > > > […] > Hi Larry, > > I don't *feel* strongly in favour or against them, but can see advantages > and disadvantages on both sides. Feeling strongly is not the same as having > a strong argument for your point of view, so just because some people have > expressed strong opinions against, I don't see why I shouldn't challenge > their reasoning, even if that does mean playing devil's advocate. > > Which is better: basing the decision on the gut feeling of a handful of > people who happen to be here now, or basing it on sound reasoning after > thinking through the implications? > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > > > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #89425 — Rowan Collins — 2015-11-25T18:47:41+00:00 URL: https://externals.io/message/89382#89425 · In reply to: #89424 guilhermeblanco@gmail.com wrote on 25/11/2015 17:58: > I can give you a good argument. > > opcache.save_comments=0 > > Make it work. Simple: remove that configuration variable, and always save doc blocks. As mentioned, my view would be that these should no longer be considered "comments", but "metadata", and that documentation and core features would be altered to reflect this. Did you think that was a killer argument, or just another thought to bring to the discussion? Because I absolutely welcome people adding to the list of pros and cons *on either side*, but I object to any attempt to shut down the discussion just because people have already made their mind up based on some gut feeling. Regards, -- Rowan Collins [IMSoP] --- ## #89427 — Rowan Collins — 2015-11-25T18:49:23+00:00 URL: https://externals.io/message/89382#89427 · In reply to: #89425 Rowan Collins wrote on 25/11/2015 18:47: > Simple: remove that configuration variable, and always save doc blocks. Thinking about it, you don't even need to do that, just add a structure in the opcache memory layout for the parsed annotations, allowing you to accelerate access to those. (Something you'd have to do anyway if the syntax was outside the docblock.) --- ## #89426 — Pedro Cordeiro — 2015-11-25T18:50:13+00:00 URL: https://externals.io/message/89382#89426 · In reply to: #89424 On top of it, it'd break obfuscators like Zend Guard. 2015-11-25 15:58 GMT-02:00 guilhermeblanco@gmail.com < guilhermeblanco@gmail.com>: > I can give you a good argument. > > opcache.save_comments=0 > > Make it work. > > On Wed, Nov 25, 2015 at 12:48 PM, Rowan Collins > wrote: > > > […] > the > > […] > a > > […] > having > > […] > have > > […] > > > -- > Guilherme Blanco > MSN: guilhermeblanco@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada --- ## #89428 — guilhermeblanco@gmail.com — 2015-11-25T19:02:37+00:00 URL: https://externals.io/message/89382#89428 · In reply to: #89426 Hi Rowan, If you're in a shared hosting, you can't "simply" remove the configuration variable. Relying on extensions or configuration flags to support core language features is very bad. We don't have flags that can turn IF support off for example, why we would have that for annotations? I can bring more cons if you want... like how/when to parse "use" calls in a docblock? I mainly want to address the need of this class: https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/TokenParser.php I've exhausted to death pros and cons of every single part. The biggest problem of not realizing this is a core feature and pushing so hard to docblock is that as soon as this is blinded to some people, others will say "oh, so that doesn't need to be in core and can be a PECL extension". Now re-read my email from the beginning about shared hosting, you just entered in an infinite loop. On Wed, Nov 25, 2015 at 1:50 PM, Pedro Cordeiro wrote: > On top of it, it'd break obfuscators like Zend Guard. > > 2015-11-25 15:58 GMT-02:00 guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com>: > > > […] > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- Next page: https://externals.io/message/89382.md?page=2