On Wed, 02 Apr 2003, Zeev Suraski wrote:
> >We don't want to apply this doc comment to class Bar, so it needs to be
> >reset on every statement, basically. Isn't that right?
>
> Probably, yes. I think Alan mentioned it.
So it would be enough to reset it in unticked_statement rule?
-Andrei
At 18:51 02/04/2003, Andrei Zmievski wrote:
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> I don't really like the idea of cluttering the parser with additional
rules
> if it's not really necessary. I think that the idea proposed by Alan is
> actually the best way to go (keep the last comment in a gl
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> I don't really like the idea of cluttering the parser with additional rules
> if it's not really necessary. I think that the idea proposed by Alan is
> actually the best way to go (keep the last comment in a global, use and
> reset it in the next relev
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> How about:
> if ($a
> /**
> $a is great variable */
> || $b) {
>
> }
>
> I'm sure I can find other more realistic examples which would break. I
> don't know why I didn't think of it before but I think having this in the
> parser is impossible.
At 18:38 02/04/2003, Andrei Zmievski wrote:
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our strate
At 10:41 AM 4/2/2003 -0500, Andrei Zmievski wrote:
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> 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.
> T
At 10:38 AM 4/2/2003 -0500, Andrei Zmievski wrote:
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> 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
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our strategy then, and tie
> doc comments to the re
On Wed, 02 Apr 2003, Lance Lovette wrote:
> 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
ilto:[EMAIL PROTECTED]
> Sent: Wednesday, April 02, 2003 1:11 AM
> To: Sebastian Bergmann; [EMAIL PROTECTED]
> 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 i
On Wed, 02 Apr 2003, Alan Knowles wrote:
> http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?r1=1.403&r2=1.404&ty=h&num=10
>
> removed the T_DOC_COMMENT from being ignored by zendlex -
>
> looks like at the moment, optional_doc_comment is splattered all over
> the parser.
>
> the other way
http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?r1=1.403&r2=1.404&ty=h&num=10
removed the T_DOC_COMMENT from being ignored by zendlex -
looks like at the moment, optional_doc_comment is splattered all over
the parser.
the other way to do this (is what phpcodedoc does) is just to
remembe
At 10:17 02/04/2003, Andi Gutmans wrote:
At 10:13 AM 4/2/2003 +0300, Zeev Suraski wrote:
At 09:23 02/04/2003, Andi Gutmans wrote:
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> w
At 10:13 AM 4/2/2003 +0300, Zeev Suraski wrote:
At 09:23 02/04/2003, Andi Gutmans wrote:
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> what's important because interfaces are fu
At 09:23 02/04/2003, Andi Gutmans wrote:
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> 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-styli
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> 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
On Wed, 2 Apr 2003, Sascha Schumann wrote:
> On Wed, 2 Apr 2003, Andi Gutmans wrote:
>
> > 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,
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> 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 t
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:
works, but
causes
Parse error: parse error, unexpected T_VAR,
Current HEAD:
works, but
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://wish
21 matches
Mail list logo
