Am 18.10.2007 um 18:06 schrieb Stanislav Malyshev:
I would prefer Stan's patch to allow keyword to be used as
class/method/function name. At the very least (the patch has
A note here: the solution we have doesn't allow _any_ keyword to be
used as name. Only import keyword, for supporting old
why even discuss import? We already decided for use and reserved is as a
"We" being?
keyword long ago. And for the other one, well package is anyway much better.
I vaguely remember having discussion on this already...
Anyway, package won't solve any of the problems we are currently
discus
Hello Stanislav,
why even discuss import? We already decided for use and reserved is as a
keyword long ago. And for the other one, well package is anyway much better.
marcus
Thursday, October 18, 2007, 7:04:28 PM, you wrote:
>> Others: concern about T_IMPORT breaking BC is also moot. There i
Stanislav Malyshev wrote:
>> Are there already any results on these checks?
>
> Looks like we have the simple patch that allows to use "import" as
> method name, function name and class name. If we didn't discover any
> problems with it then import stays.
Hi,
If you're talking about my patch [1]
Others: concern about T_IMPORT breaking BC is also moot. There is an
instant parse error on this declaration:
This is not related to BC. What is related to BC is that applications
like Propel or Wordpress stopping working with 5.3 since they use import
as identifier. Unfortunately we also h
I would prefer Stan's patch to allow keyword to be used as
class/method/function name. At the very least (the patch has
A note here: the solution we have doesn't allow _any_ keyword to be used
as name. Only import keyword, for supporting old code.
--
Stanislav Malyshev, Zend Software Architect
Hi,
On 10/18/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-10-18 at 12:08 +0200, Pierre wrote:
> > I would prefer Stan's patch to allow keyword to be used as
> > class/method/function name. At the very least (the patch has
> > unsolvable issues), I have to agree with Andi, we sh
Hi,
On Thu, 2007-10-18 at 12:08 +0200, Pierre wrote:
> I would prefer Stan's patch to allow keyword to be used as
> class/method/function name. At the very least (the patch has
> unsolvable issues), I have to agree with Andi, we should just go with
> "use" (codesearch returns less than 10 results
On 10/18/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Main problem I have right now after digging deeper is that any such "fix" in
> the parser will mean that tokenizers and syntax highlighters will not treat
> keywords like "import" correctly. Fixing this would require them to do
> parsing whi
On 10/18/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Main problem I have right now after digging deeper is that any such "fix" in
> the parser will mean that tokenizers and syntax highlighters will not treat
> keywords like "import" correctly. Fixing this would require them to do
> parsing whi
ter; Sebastian Bergmann;
> internals@lists.php.net
> Subject: Re: [PHP-DEV] T_IMPORT vs. T_USE
>
> > Are there already any results on these checks?
>
> Looks like we have the simple patch that allows to use "import" as
> method name, function name and class name.
Are there already any results on these checks?
Looks like we have the simple patch that allows to use "import" as
method name, function name and class name. If we didn't discover any
problems with it then import stays.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://
Sebastian Nohn [mailto:[EMAIL PROTECTED]
> > Sent: Monday, October 01, 2007 11:16 PM
> > To: Andi Gutmans
> > Cc: Johannes Schlüter; Sebastian Bergmann; internals@lists.php.net
> > Subject: Re: [PHP-DEV] T_IMPORT vs. T_USE
> >
> > Andi Gutmans wrote:
> > &
Same here.
On 10/2/07, Ford, Mike <[EMAIL PROTECTED]> wrote:
> On 02 October 2007 07:16, Sebastian Nohn wrote:
>
> > Andi Gutmans wrote:
> > > Hi Johannes,
> > > Our preference would be to stick to "import" because I
> > think the perception many will have of "use" is that it also
> > includes fil
On 02 October 2007 07:16, Sebastian Nohn wrote:
> Andi Gutmans wrote:
> > Hi Johannes,
> > Our preference would be to stick to "import" because I
> think the perception many will have of "use" is that it also
> includes files (just based on some other languages).
I don't know much about "other la
ernals@lists.php.net
> Subject: Re: [PHP-DEV] T_IMPORT vs. T_USE
>
> Andi Gutmans wrote:
> > Hi Johannes,
> > Our preference would be to stick to "import" because I think the
> perception many will have of "use" is that it also includes files (just
>
Andi Gutmans wrote:
> Hi Johannes,
> Our preference would be to stick to "import" because I think the perception
> many will have of "use" is that it also includes files (just based on some
> other languages). That said I agree that compatibility would be an issue
> here. In fact it's even somew
Andi Gutmans schrieb:
Our preference would be to stick to "import" because I think the perception many will have of
"use" is that it also includes files (just based on some other languages). That said I agree that
compatibility would be an issue here. In fact it's even somewhat of an issue with
This would be pretty easy, in a hackish way, by adding a whole bunch of
duplicate rules T_FUNCTION T_STRING, T_FUNCTION T_IMPORT, T_FUNCTION
T_NAMESPACE and so on. A more robust way would be to move to lemon/re2c
but I'm not volunteering to do this (yet?)
probably better something like keyword_
Andi Gutmans wrote:
> Hi Johannes, Our preference would be to stick to "import" because I
> think the perception many will have of "use" is that it also includes
> files (just based on some other languages). That said I agree that
> compatibility would be an issue here. In fact it's even somewhat o
Thx.
Andi
> -Original Message-
> From: Johannes Schlüter [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 01, 2007 4:24 AM
> To: Sebastian Bergmann
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] T_IMPORT vs. T_USE
>
> Hi Sebastiann et al.,
>
>
Hi Sebastiann et al.,
On Sun, 2007-09-30 at 18:06 +0200, Sebastian Bergmann wrote:
> When we removed the namespace implementation that was scheduled for
> PHP 5.0 before PHP 5.0's release we kept the T_NAMESPACE and T_USE
> tokens for forward-compatibility.
T_NAMESPACE is new, only T_USE wasn't
When we removed the namespace implementation that was scheduled for
PHP 5.0 before PHP 5.0's release we kept the T_NAMESPACE and T_USE
tokens for forward-compatibility.
The new namespace implementation in HEAD and PHP_5_3 uses the the new
T_IMPORT token instead of T_USE thus breaking code as
23 matches
Mail list logo
