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
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
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
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
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
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
Others: concern about T_IMPORT breaking BC is also moot. There is an instant parse error on this declaration: ?php 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] -- 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:
?php
namespace whatever;
?
The only way to preserve BC (no parse error) would be to use some
weirdo syntax like
?php
new namespace(whatever);
?
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
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: ?php 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
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
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
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
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
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
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
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
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
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% 22hl=enbtnG=Search+Code -- 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% 22hl=enbtnG=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
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
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 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
