# Doc Comments cause parser errors - Thread: https://externals.io/message/587 - Original archive: https://news-web.php.net/php.internals/587 - Started by Andi Gutmans on 2003-04-02T06:10:49+00:00 - Messages: 7 - 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 --- ## #587 — Andi Gutmans — 2003-04-02T06:10:49+00:00 URL: https://externals.io/message/587#587 AFAIK, doc comments are for classes and functions only. I think this is what's important because interfaces are functions not variables. Andi At 07:50 AM 4/2/2003 +0200, Sebastian Bergmann wrote: > Current HEAD: > > class Foo { > var $foo; > } > ?> > > works, but > > class Foo { > /** > */ > var $foo; > } > ?> > > causes > > Parse error: parse error, unexpected T_VAR, expecting `T_FUNCTION` > in e:\var.php on line 5 > >-- > Sebastian Bergmann > http://sebastian-bergmann.de/ http://phpOpenTracker.de/ > > Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ --- ## #588 — Sascha Schumann — 2003-04-02T06:16:13+00:00 URL: https://externals.io/message/587#588 · In reply to: #587 > AFAIK, doc comments are for classes and functions only. I think this is > what's important because interfaces are functions not variables. Hm, so my PHP 4-stylish code would cause a parse error, if it contained a valid character like a "*" after the initiation sequence "/*"? - Sascha --- ## #590 — Andi Gutmans — 2003-04-02T06:23:44+00:00 URL: https://externals.io/message/587#590 · In reply to: #587 At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote: > > > > […] > > Hm, so my PHP 4-stylish code would cause a parse error, if it > contained a valid character like a "*" after the initiation > sequence "/*"? Oh, I didn't think of that. You are completely right. This is definitely a problem. Andrei's patch returns a token for /** */ on the parser level so only places which are allowed to have this work. This sounds like a serious flaw because any place which has such comments will fail. I guess we'll need to revert his patch and try to think of a completely different way of doing it (unless someone has a good idea of how to solve this problem). Andi --- ## #589 — Derick Rethans — 2003-04-02T06:31:35+00:00 URL: https://externals.io/message/587#589 · In reply to: #588 > > > > […] > > Hm, so my PHP 4-stylish code would cause a parse error, if it > contained a valid character like a "*" after the initiation > sequence "/*"? Sounds indeed like something we don't want, as almost all the documentors use this. Derick -- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ --- ## #603 — Lance Lovette — 2003-04-02T15:12:37+00:00 URL: https://externals.io/message/587#603 · In reply to: #587 Can the purpose of doc comments be clarified? Why aren't class variables important enough to document? I think everything exposed by a class - variables, methods, constants, etc. - are all equally important and should be documented. > -----Original Message----- > From: Andi Gutmans [mailto:andi@zend.com] > Sent: Wednesday, April 02, 2003 1:11 AM > To: Sebastian Bergmann; internals@lists.php.net > Subject: Re: [PHP-DEV] Doc Comments cause parser errors > > > AFAIK, doc comments are for classes and functions only. I think this is > what's important because interfaces are functions not variables. > > Andi > > At 07:50 AM 4/2/2003 +0200, Sebastian Bergmann wrote: > > […] > http://phpOpenTracker.de/ > > […] > http://wishlist.sebastian-bergmann.de/ --- ## #604 — Andrei Zmievski — 2003-04-02T15:30:39+00:00 URL: https://externals.io/message/587#604 · In reply to: #603 > Can the purpose of doc comments be clarified? Why aren't class variables > important enough to document? I think everything exposed by a class - > variables, methods, constants, etc. - are all equally important and should > be documented. The problem is finding the storage for them. Classes/functions have internal structures that we can store doc comments in. Constants and variables, alas, don't. -Andrei http://www.gravitonic.com/ * Proximity bug: when the program crashes in front of important visitors. * --- ## #606 — Andrei Zmievski — 2003-04-02T15:41:24+00:00 URL: https://externals.io/message/587#606 · In reply to: #590 > Oh, I didn't think of that. You are completely right. This is definitely a > problem. Andrei's patch returns a token for /** */ on the parser level so > only places which are allowed to have this work. > This sounds like a serious flaw because any place which has such comments > will fail. I guess we'll need to revert his patch and try to think of a > completely different way of doing it (unless someone has a good idea of how > to solve this problem). No, it won't fail. Look: statement: unticked_statement { zend_do_ticks(TSRMLS_C); } | doc_comment { zend_do_free(&$1 TSRMLS_CC); } unticked_statement { zend_do_ticks(TSRMLS_C); } ; This allows doc comments before any non-declarative statement. The only remaining problem is having doc comments before class vars and constants. If you think it's better to go with the approach that Alan outlined, I can live with that too, but it seems easier to handle this in the parser rather than in zend_do_* functions and also having to reset the doc comment for each statement. -Andrei http://www.gravitonic.com/ The Feynman problem solving algorithm: 1) Write down the problem. 2) Think real hard. 3) Write down the answer.