Re: [PHP-DEV] T_IMPORT vs. T_USE
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 code. That certainly sounds nasty. Why not just use "use" then, it's reserved already anyway. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 discussing - there's a bunch of apps using package as identifier, starting with PEAR. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 is an >> instant parse error on this declaration: >> >> > namespace whatever; >> ?> > 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 have some package using "namespace" > as identifier (e.g. ezPublish for methods, mediawiki for class) but not > too many. > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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], the restriction is only lifted for
method names. I don't think it is even possible for functions:
function foreach() {return array(1);}
foreach(foreach() as $oops);
The above code requires PHP to parse all the way to the T_AS prior to
determining whether the first foreach statement is a T_STRING or a
T_FOREACH.
It may be possible for classes, but is much more complex, so I did not
go that route. For instance:
class class {
static function class(){}
}
$a = class::class();
$a = new class;
We can safely expect a T_STRING after T_NEW, but in open global scope,
we would need to match an identifier plus :: before matching any
keyword. It is possible, but somewhat messier.
Methods, on the other hand, are simple, as the 11-line patch
demonstrates. We always know that stuff after T_OBJECT_OPERATOR and
T_PAMMAYAMMAETC should be a T_STRING. In fact, this is already possible
for variables as in this example (T_STRING returned for "class"):
class blah {
var $class;
}
$a = new blah;
$a->class = 1;
but as I said in the bug report, this example breaks (T_CLASS returned
for "class"):
class blah {
var $class;
}
$a = new blah;
$a-> class = 1;
because the lexer fails to take into account whitespace properly when
looking for a property (also fixed in my patch).
Andi: your concern about highlighters is moot - implementing the changes
to always detect T_STRING after :: or -> is trivial no matter how dumb
the highlighter is :).
Others: concern about T_IMPORT breaking BC is also moot. There is an
instant parse error on this declaration:
The only way to "preserve" BC (no parse error) would be to use some
weirdo syntax like
This might be an option, but I don't see much point - the code still
will fail to work because it uses namespaces. Namespaces are new, the
syntax *should* break BC, otherwise we'll get all kinds of weird bug
reports from users using PHP versions that are too old.
My patch prevents breakage of Zend Framework and Symfony because nobody
who has followed the CS rule of "use underscores to avoid conflicting
with internal classes" is using "class import" "class namespace" or
interface equivalents.
Greg
[1] http://bugs.php.net/bug.php?id=28261
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 have some package using "namespace" as identifier (e.g. ezPublish for methods, mediawiki for class) but not too many. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 should just go with > > "use" (codesearch returns less than 10 results :). > > The point about using "use" is that "use" is already a reserved keyword > in PHP - therefore we can't break anything by using "use" for > namespaces. Oh, I missed this point. So what are we waiting for to switch? It will ease our life to test our existing code under 5.3 without having to create specific branches (or breaking bc). >So in this single case we have a chance of using a keyword > withou breaking anything (while we still might break stuff due to the > "namespace" keyword) :-) The namespace keyword is less a problem than import. It is mostly used in areas where php5+ provides native solution (for example xml or soap like in ezpublish, mostly php4 code). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 :). The point about using "use" is that "use" is already a reserved keyword in PHP - therefore we can't break anything by using "use" for namespaces. So in this single case we have a chance of using a keyword withou breaking anything (while we still might break stuff due to the "namespace" keyword) :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 which in many cases you don't want to do. There are a lot of > utilities and tools which depend on such behavior. > Even if it's just for this reason it may be better if we stick to the "a > keyword is a keyword" rule and don't try and outsmart ourselves (other > languages like C have discovered the same issues and stuck to the keyword > only rule too). So it may make most sense to go ahead and use "use". If we stick to this rule, we can't add new keywords in minor/patch versions. (x.y+1 or x.y.z+1) as it break BC. With import, a lot of codes is affected even if they use "import" as method name (said already, add symfony to the list). I really don't care about use or import but for what I see, import is going to break (as said already) a lot of apps/codes out ther (add symfony to the list). 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 :). Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 which in many cases you don't want to do. There are a lot of > utilities and tools which depend on such behavior. In my opinion, this is a problem with those syntax highlighters. This problem can be nicely solved and textmate is an example of that. It still relies on regular expressions, but it is context-aware I am definitely on "less keywords is better" side -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] T_IMPORT vs. T_USE
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 which in many cases you don't want to do. There are a lot of utilities and tools which depend on such behavior. Even if it's just for this reason it may be better if we stick to the "a keyword is a keyword" rule and don't try and outsmart ourselves (other languages like C have discovered the same issues and stuck to the keyword only rule too). So it may make most sense to go ahead and use "use". Andi > -Original Message- > From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 17, 2007 12:58 PM > To: Sebastian Nohn > Cc: Andi Gutmans; Johannes Schlü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. If we didn't discover any > problems with it then import stays. > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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. If we didn't discover any problems with it then import stays. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Are there already any results on these checks? - Sebastian On 10/2/07, Andi Gutmans <[EMAIL PROTECTED]> wrote: > Of course not (and I know we use import in a few places in ZF) which is why I > want to see whether it makes sense to allow reserved words. The basic parsing > rule would be easy but we need to check how many other areas this might > affect. Wouldn't want to introduce any more inconsistencies. If it ends up > being too much of a bother we can just end up using "use". > > Andi > > > -Original Message- > > From: 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: > > > 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 of an issue with > > "namespace" which is probably also used quite a bit esp. in relation to > > XML. > > > > I don't think people will care much about use vs. import > > perception-wise. But they will care a lot if it breaks their software. > > Just to name two popular products that will break (Johannes can for > > sure > > tell more, he googled for it): Serendipity & Zend Framework. At least > > breaking the latter should not be "your" preference, I hope. > > > > - Sebastian > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 files (just based on some other languages). > > I don't know much about "other languages", but purely in terms of English I > would expect "use" to work with something that's already lying around ready > to be used, whereas "import" would go and fetch something from somewhere else > and make it ready to be used in the current context. In other words, I would > probably expect "import" to potentially have an implied "include", and "use" > not to. > > But then, in the global polyglot marketplace, this argument may not have much > force!! ;) > > Cheers! > > Mike > > - > Mike Ford, Electronic Information Services Adviser, > JG125, The Headingley Library, > James Graham Building, Leeds Metropolitan University, > Headingley Campus, LEEDS, LS6 3QS, United Kingdom > Email: [EMAIL PROTECTED] > Tel: +44 113 812 4730 Fax: +44 113 812 3211 > > > To view the terms under which this email is distributed, please go to > http://disclaimer.leedsmet.ac.uk/email.htm > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Giedrius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] T_IMPORT vs. T_USE
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 languages", but purely in terms of English I would expect "use" to work with something that's already lying around ready to be used, whereas "import" would go and fetch something from somewhere else and make it ready to be used in the current context. In other words, I would probably expect "import" to potentially have an implied "include", and "use" not to. But then, in the global polyglot marketplace, this argument may not have much force!! ;) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, JG125, The Headingley Library, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 812 4730 Fax: +44 113 812 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] T_IMPORT vs. T_USE
Of course not (and I know we use import in a few places in ZF) which is why I want to see whether it makes sense to allow reserved words. The basic parsing rule would be easy but we need to check how many other areas this might affect. Wouldn't want to introduce any more inconsistencies. If it ends up being too much of a bother we can just end up using "use". Andi > -Original Message- > From: 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: > > 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 of an issue with > "namespace" which is probably also used quite a bit esp. in relation to > XML. > > I don't think people will care much about use vs. import > perception-wise. But they will care a lot if it breaks their software. > Just to name two popular products that will break (Johannes can for > sure > tell more, he googled for it): Serendipity & Zend Framework. At least > breaking the latter should not be "your" preference, I hope. > > - Sebastian > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 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 "namespace" which is > probably also used quite a bit esp. in relation to XML. I don't think people will care much about use vs. import perception-wise. But they will care a lot if it breaks their software. Just to name two popular products that will break (Johannes can for sure tell more, he googled for it): Serendipity & Zend Framework. At least breaking the latter should not be "your" preference, I hope. - Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 "namespace" which is probably also used quite a bit esp. in relation to XML. You mean like "import" includes files in python? ;) Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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_as_identifier -> T_IMPORT | T_NAMESPACE | etc. and then T_FUNCTION keyword_as_identifier, T_CLASS keyword_as_identifier etc. But we have to watch out for expressions - there could be conflicts... That's what we should check. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 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 "namespace" which is probably also used quite a bit > esp. in relation to XML. > > What I'd like to do is see if it's feasible to support reserved words > as identifiers. It should be possible but we need to see if it makes > sense, how it affects consistency, and if we do it what identifiers > we'd do it for (or all?). 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?) :) Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] T_IMPORT vs. T_USE
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 of an issue with "namespace" which is probably also
used quite a bit esp. in relation to XML.
What I'd like to do is see if it's feasible to support reserved words as
identifiers. It should be possible but we need to see if it makes sense, how it
affects consistency, and if we do it what identifiers we'd do it for (or all?).
We probably won't get to this until after our conference next week so my
suggestion is to keep it as-is for now and then revisit it. We're still far
enough off from the release so that we don't need to finalize today.
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.,
>
> 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 removed back then. afaik. ;-)
>
> > 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 "import" is
> now
> > a reserved word.
> >
> > We should, IMHO, drop T_IMPORT and change the namespace
> implementation
> > to use T_USE.
> >
> > Thoughts?
>
> Well, import seems to be a word used quite often in PHP for method
> names, after I found some code breaking I did a short test using
> Google's Codesearch[1] to look for method calls using "->import(" and
> got "about 300" results including major apps like horde, tikiwiki,
> typo3
> and wordpress.
>
> Therefor I think it's worth to at least think about using the already
> reserved, but not used, keyword "use". From taking a look at the
> language (the English one in this case ;-)) a sentence like "use
> Namespace::SomeClass as SomeClass" makes perfect sense to me - but I
> don't know much about the concept of Perl's (and other language's)
> meaning of "use", BUT, we're neither Java nor Perl but PHP so we should
> use the keyword fitting best to PHP...
>
> If we can agree on the change I can write a patch changing the token
> and
> renaming the internal stuff accordingly.
>
> johannes
>
> [1] http://www.google.com/codesearch?q=lang%3Aphp+%22-%3Eimport%28%
> 22&hl=en&btnG=Search+Code
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
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 removed back then. afaik. ;-)
> 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 "import" is now
> a reserved word.
>
> We should, IMHO, drop T_IMPORT and change the namespace implementation
> to use T_USE.
>
> Thoughts?
Well, import seems to be a word used quite often in PHP for method
names, after I found some code breaking I did a short test using
Google's Codesearch[1] to look for method calls using "->import(" and
got "about 300" results including major apps like horde, tikiwiki, typo3
and wordpress.
Therefor I think it's worth to at least think about using the already
reserved, but not used, keyword "use". From taking a look at the
language (the English one in this case ;-)) a sentence like "use
Namespace::SomeClass as SomeClass" makes perfect sense to me - but I
don't know much about the concept of Perl's (and other language's)
meaning of "use", BUT, we're neither Java nor Perl but PHP so we should
use the keyword fitting best to PHP...
If we can agree on the change I can write a patch changing the token and
renaming the internal stuff accordingly.
johannes
[1] http://www.google.com/codesearch?q=lang%3Aphp+%22-%3Eimport%28%
22&hl=en&btnG=Search+Code
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] T_IMPORT vs. T_USE
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 "import" is now a reserved word. We should, IMHO, drop T_IMPORT and change the namespace implementation to use T_USE. Thoughts? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
