Re: [PHP-DEV] Some strange bug
It is very informative, but not resolve the problem, php completely ignored my max_execution_teme setup with any SAPI, in all cases 2015-06-11 14:57 GMT+03:00 Andrew Kluev kluev.and...@gmail.com: And php7 not working too. php7 -v PHP 7.0.0-dev (cli) (built: Mar 30 2015 12:26:36) (DEBUG) Copyright (c) 1997-2015 The PHP Group Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies 2015-06-11 14:55 GMT+03:00 Andrew Kluev kluev.and...@gmail.com: It is very informative, but not resolve the problem, php completely ignored my max_execution_teme setup with any SAPI, in all cases 2015-06-11 14:42 GMT+03:00 Johannes Schlüter johan...@schlueters.de: On Thu, 2015-06-11 at 14:25 +0300, Andrew Kluev wrote: sleep(3); [...] This is a bug or something I do not know about php? Max execution time is working a bit dependent on the operating system. On Windows it is using the elapsed time (wall clock time) on Linux systems the CPU time. Thus on windows the sleep counts whereas on Linux no time is spent during sleep(). The same difference happens when other processes are on CPU and your PHP script was taken off CPU for other reasons. For details see MSDN on CreateTimerQueueTimer for Windows and the setitimer man page with (ITIMER_PROF option) for Linux/Unix for a start. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682485% 28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms682485%28v=vs.85%29.aspx http://linux.die.net/man/2/setitimer johannes
Re: [PHP-DEV] Array dereferencing of scalars
Yasuo Ohgaki wrote on 11/06/2015 00:50:
If PHP should return NULL always against NULL variables, we may be better
to
reconsider these behavior.
[yohgaki@dev Download]$ php
?php
$v = NULL;
$$v;
PHP Notice: Undefined variable: in - on line 3
This is not complaining that $v is NULL, it is warning you the same as
if you wrote $v = 'some_name_you_never_assigned_to'; $$v;
Somewhat surprisingly, you can actually assign to the variable whose
name is NULL: http://3v4l.org/5pXJg
[yohgaki@dev Download]$ php
?php
$v = NULL;
$v();
PHP Fatal error: Uncaught EngineException: Function name must be a string
in -:3
Stack trace:
#0 {main}
thrown in - on line 3
This one has given a different message because of it being a non-string
value, but would be equally fatal if you tried to call any undefined
function. Would coercing NULL to an imaginary function which returns
NULL actually be useful for anything?
I don't care much whether these yield NULL always or raise error/exception,
but there should be consistency.
I see no reason why these cases need to be consistent, just because they
both involve NULLs. It's all about the action you invoke, not just the
value something's interpreted as.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Some strange bug
I have code:
-
echo 'php_sapi_name: '.php_sapi_name().PHP_EOL;
echo 'max_input_time: '.ini_get('max_input_time').PHP_EOL;
echo 'max_execution_time: '.ini_get('max_execution_time').PHP_EOL;
set_time_limit(2);
echo 'max_input_time: '.ini_get('max_input_time').PHP_EOL;
echo 'max_execution_time: '.ini_get('max_execution_time').PHP_EOL;
sleep(3);
echo 'how it works?'.PHP_EOL;
-
And it's output
-
php_sapi_name: cli
max_input_time: -1
max_execution_time: 0
max_input_time: -1
max_execution_time: 2
how it works?
-
or
-
php_sapi_name: fpm-fcgimax_input_time: 60max_execution_time: 30max_input_time:
60max_execution_time: 2how it works?
-
I have no idea why this is happening. On Windows PHP 5.4.13 (cli)(built:
Mar 15 2013 02:07:14) it writes (Maximum execution time of 2 seconds
exceeded)
Some info about my pc:
php -v:
PHP 5.6.7-1 (cli) (built: Mar 24 2015 12:30:15)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend
Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans
uname -a:
Linux andrew-deb 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13)
x86_64 GNU/Linux
php -i:
http://pastebin.com/vzeHZJn1
This is a bug or something I do not know about php?
Re: [PHP-DEV] Some strange bug
On Thu, 2015-06-11 at 14:25 +0300, Andrew Kluev wrote: sleep(3); [...] This is a bug or something I do not know about php? Max execution time is working a bit dependent on the operating system. On Windows it is using the elapsed time (wall clock time) on Linux systems the CPU time. Thus on windows the sleep counts whereas on Linux no time is spent during sleep(). The same difference happens when other processes are on CPU and your PHP script was taken off CPU for other reasons. For details see MSDN on CreateTimerQueueTimer for Windows and the setitimer man page with (ITIMER_PROF option) for Linux/Unix for a start. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682485% 28v=vs.85%29.aspx http://linux.die.net/man/2/setitimer johannes signature.asc Description: This is a digitally signed message part
Re: [PHP-DEV] Request for php-src karma
Anatol Belski wrote: Christoph, please don't forget to note the changes in the NEWS and/or UPGRADING where appropriate. Also don't forget to check the lower branches where your fixes could be profitable. Thanks for the hints. As I understand it, I should inform the release managers about changes in the respective branches.[1][2] What is the best way to do so? [1] https://wiki.php.net/vcs/gitworkflow?s[]=releases[]=manager [2] https://bugs.php.net/bug.php?id=68812#1433889583 (stas' comment) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some strange bug
Andrew Kluev wrote: It is very informative, but not resolve the problem, php completely ignored my max_execution_teme setup with any SAPI, in all cases As Johannes wrote: [...] whereas on Linux no time is spent during sleep(). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for php-src karma
Hi Anatol, Anatol Belski wrote: Hi Christoph, -Original Message- From: Christoph Becker [mailto:cmbecke...@gmx.de] Sent: Thursday, June 11, 2015 1:03 PM To: Anatol Belski; internals@lists.php.net Subject: Re: [PHP-DEV] Request for php-src karma Anatol Belski wrote: Christoph, please don't forget to note the changes in the NEWS and/or UPGRADING where appropriate. Also don't forget to check the lower branches where your fixes could be profitable. Thanks for the hints. As I understand it, I should inform the release managers about changes in the respective branches.[1][2] What is the best way to do so? [1] https://wiki.php.net/vcs/gitworkflow?s[]=releases[]=manager [2] https://bugs.php.net/bug.php?id=68812#1433889583 (stas' comment) Please note also that there is a number of README files in the php-src dir, like this one http://git.php.net/?p=php-src.git;a=blob;f=README.GIT-RULES . In general, if you fix a bug and it's worth it to mention, you just push a patch and add note into the NEWS. If in doubt, better to ask the RM whether the patch is ok for that particular branch, of course. Pushing to the 5.4 branch is another story as only security fixes go in there, so it has to be cleared out explicitly. The same will apply to any other branch in security mode later, fe 5.5 which active development period ends soon. Also as far as I see, the patch from the ticket you link was not merged up as in accordance to the git workflow. The NEWS file has to be updated in all the active branches but master, usually. Otherwise, if a fix in master only - so only NEWS in master. As we now have no explicit PHP-7.0 branch, NEWS should be updated in master as well until PHP-5.4 is EOL. Thanks for the explanation. That clarifies my questions. :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some strange bug
Wow! Now I understand. Thank you for the explanation
2015-06-11 15:10 GMT+03:00 Johannes Schlüter johan...@schlueters.de:
As said: It looks at CPU time. sleep doesn't require CPU time. Try with
something like while(true){} which keeps PHP on CPU
$ cat test.php
?php
echo 'php_sapi_name: '.php_sapi_name().PHP_EOL;
echo 'max_input_time: '.ini_get('max_input_time').PHP_EOL;
echo 'max_execution_time: '.ini_get('max_execution_time').PHP_EOL;
set_time_limit(2);
echo 'max_input_time: '.ini_get('max_input_time').PHP_EOL;
echo 'max_execution_time: '.ini_get('max_execution_time').PHP_EOL;
while (true) {}
echo 'how it works?'.PHP_EOL;
$ ./sapi/cli/php -v
PHP 7.0.0-dev (cli) (built: Jun 11 2015 14:04:07) (DEBUG)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies
$ time ./sapi/cli/php test.php
php_sapi_name: cli
max_input_time: -1
max_execution_time: 0
max_input_time: -1
max_execution_time: 2
Fatal error: Maximum execution time of 2 seconds exceeded in test.php on
line 11
real0m2.062s
user0m2.005s
sys 0m0.016s
On Thu, 2015-06-11 at 14:55 +0300, Andrew Kluev wrote:
It is very informative, but not resolve the problem, php completely
ignored my max_execution_teme setup with any SAPI, in all cases
2015-06-11 14:42 GMT+03:00 Johannes Schlüter johan...@schlueters.de:
On Thu, 2015-06-11 at 14:25 +0300, Andrew Kluev wrote:
sleep(3);
[...]
This is a bug or something I do not know about php?
Max execution time is working a bit dependent on the operating
system.
On Windows it is using the elapsed time (wall clock time) on
Linux
systems the CPU time. Thus on windows the sleep counts whereas
on Linux
no time is spent during sleep(). The same difference happens
when other
processes are on CPU and your PHP script was taken off CPU for
other
reasons.
For details see MSDN on CreateTimerQueueTimer for Windows and
the
setitimer man page with (ITIMER_PROF option) for Linux/Unix
for a start.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682485%
28v=vs.85%29.aspx
http://linux.die.net/man/2/setitimer
johannes
RE: [PHP-DEV] Request for php-src karma
Hi Christoph, -Original Message- From: Christoph Becker [mailto:cmbecke...@gmx.de] Sent: Thursday, June 11, 2015 1:03 PM To: Anatol Belski; internals@lists.php.net Subject: Re: [PHP-DEV] Request for php-src karma Anatol Belski wrote: Christoph, please don't forget to note the changes in the NEWS and/or UPGRADING where appropriate. Also don't forget to check the lower branches where your fixes could be profitable. Thanks for the hints. As I understand it, I should inform the release managers about changes in the respective branches.[1][2] What is the best way to do so? [1] https://wiki.php.net/vcs/gitworkflow?s[]=releases[]=manager [2] https://bugs.php.net/bug.php?id=68812#1433889583 (stas' comment) Please note also that there is a number of README files in the php-src dir, like this one http://git.php.net/?p=php-src.git;a=blob;f=README.GIT-RULES . In general, if you fix a bug and it's worth it to mention, you just push a patch and add note into the NEWS. If in doubt, better to ask the RM whether the patch is ok for that particular branch, of course. Pushing to the 5.4 branch is another story as only security fixes go in there, so it has to be cleared out explicitly. The same will apply to any other branch in security mode later, fe 5.5 which active development period ends soon. Also as far as I see, the patch from the ticket you link was not merged up as in accordance to the git workflow. The NEWS file has to be updated in all the active branches but master, usually. Otherwise, if a fix in master only - so only NEWS in master. As we now have no explicit PHP-7.0 branch, NEWS should be updated in master as well until PHP-5.4 is EOL. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array dereferencing of scalars
On 11 June 2015 at 09:59, Rowan Collins rowan.coll...@gmail.com wrote:
Yasuo Ohgaki wrote on 11/06/2015 00:50:
If PHP should return NULL always against NULL variables, we may be better
to
reconsider these behavior.
[yohgaki@dev Download]$ php
?php
$v = NULL;
$$v;
PHP Notice: Undefined variable: in - on line 3
This is not complaining that $v is NULL, it is warning you the same as if
you wrote $v = 'some_name_you_never_assigned_to'; $$v;
Somewhat surprisingly, you can actually assign to the variable whose name
is NULL: http://3v4l.org/5pXJg
This is actually just converting $v to a string and using this as the
variable name to look up in the symbol table: http://3v4l.org/Z1fWs
(obvious I suppose, just to clarify)
[yohgaki@dev Download]$ php
?php
$v = NULL;
$v();
PHP Fatal error: Uncaught EngineException: Function name must be a string
in -:3
Stack trace:
#0 {main}
thrown in - on line 3
This one has given a different message because of it being a non-string
value, but would be equally fatal if you tried to call any undefined
function. Would coercing NULL to an imaginary function which returns NULL
actually be useful for anything?
I don't care much whether these yield NULL always or raise
error/exception,
but there should be consistency.
I see no reason why these cases need to be consistent, just because they
both involve NULLs. It's all about the action you invoke, not just the
value something's interpreted as.
I think what Yasuo is saying is that the function symbol lookup has a type
check and an early bail-out if the type doesn't make sense - even though in
theory the same string cast behaviour could be applied to dynamic function
calls.
I'm inclined to agree that we should have consistency here, and that the
current behaviour in a function context is the correct one. A couple of
(IMO) good arguments for this:
- The function behaviour gives a more explanatory and useful error message
- This is definitely a programming error, there is no valid reason to use
NULL as a variable name in this manner. It amounts to what many/most other
languages would consider to be a null pointer exception or equivalent,
and the more useful error message may help track down the error quicker
(one might look for a case where the empty string was assigned, instead of
looking for a case where it may be NULL).
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Packed array is not fast?
Hi all, I've tried to see how packed array is faster with following code http://3v4l.org/TQd6c I confirmed when start index is non-zero, hash is used by zend_hash_index_find(). I got following result. (with much larger number of elements/loops) Fedora 22 + current master without --enable-debug 1st Time is total execution time. 2nd Time is the time spent by for loop Hash [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.7903809547424 Time: 1.1529920101166 [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.8049499988556 Time: 1.1719739437103 Packed [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.7407248020172 Time: 1.1594388484955 [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.7248120307922 Time: 1.1530420780182 Packed array is not so fast, even if zend_hash.c seems much faster with packed array. Just FYI. Regards, P.S. Am I doing something wrong? HHVM seems to have optimization margins for hash and loop. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Array dereferencing of scalars
On 11/06/2015 21:22, Chris Wright wrote: I'm inclined to agree that we should have consistency here, and that the current behaviour in a function context is the correct one. A couple of (IMO) good arguments for this: - The function behaviour gives a more explanatory and useful error message - This is definitely a programming error, there is no valid reason to use NULL as a variable name in this manner. It amounts to what many/most other languages would consider to be a null pointer exception or equivalent, and the more useful error message may help track down the error quicker (one might look for a case where the empty string was assigned, instead of looking for a case where it may be NULL). Well, if you were to model it precisely on the function case, the *consistent* behaviour would be to error on any non-string value (e.g. $v = 42; $$v;) but not a string which is an illegal variable name ($v = '42'; $v(); just complains that function 42 doesn't exist, not that it never could). A more useful approach would perhaps be to look at what should be a valid function name, and what should be a valid variable name, and throw an error if dynamic access is used to by-pass either restriction. For instance, this doesn't currently complain about the fact that @ is clearly nonsensical as either a function or a variable: $foo = '@'; var_dump($$foo); $foo(); And nor does the empty string, which seems no less obvious a bug than a NULL: $foo = ''; var_dump($$foo); $foo(); -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.6.10 is available
Hello! The PHP development team announces the immediate availability of PHP 5.6.10. Several bugs have been fixed as well as several security issues into some bundled librairies (CVE-2015-3414, CVE-2015-3415, CVE-2015-3416, CVE-2015-2325 and CVE-2015-2326). All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.10 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/. The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.10 Julien Pauli Ferenc Kovacs
Re: [PHP-DEV] Migrating PHP classes to built in namespace
Yasuo Ohgaki wrote in message news:CAGa2bXZvuqV4Kwru+wUL-bfTb9_tnv=l16reu-+w+uajx4h...@mail.gmail.com... Hi Jakub, On Thu, Jun 11, 2015 at 7:43 AM, Jakub Kubícek kelerest...@gmail.com wrote: This is weird and ugly what you're fabricating here. The PHP classes should be all in global namespace. I am really against some namespacing of them. It may seems weird if you aren't familiar with languages support this kind of feature. However, you'll find many languages support this or similar. JavaScript is one of them. JavaScript allows to override any functions, for example. It's works like importing other namespace function into root. i.e. Provide different feature with the same name. For long term PHP evolution, having ability to import some namespace into root namespace is great feature. i.e. API/Module version up. We can provide both old and new during migration. Use of namespace is better approach because it may give us super clean global namespace also. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net The fact that other languages have this feature should not be a reason to add it to PHP, especially as it would provide a huge BC break with absolutely no practical, only theoretical, benefits. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 7.0.0alpha1 Released for Testing!
Hi, The first alpha for 7.0.0 was just released and can be downloaded from: https://downloads.php.net/~ab/ The Windows binaries are available at http://windows.php.net/qa/ This is the start of a new PHP era! Thanks everyone who made and helped to make this happen. From now on we are looking straight forward to get the final in time. Please test it carefully, and report any bugs in the bug system. Alpha 2 will be tagged on Tuesday 23th and released on Thursday 25th. Regards, Kalle Sommer Nielsen, Anatol Belski and Ferenc Kovacs -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR #1325 - array_column() for array of objects
On 12 Jun 2015, at 10:00 am, Xinchen Hui larue...@php.net wrote: Hey: On Fri, Jun 12, 2015 at 9:31 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi, I've created a PR here: https://github.com/php/php-src/pull/1325 This enhancement allows for properties on objects to work in the same way as arrays for the inner elements of the main array. IMO, it is called (array)_column... Please read more carefully, it's about supporting objects as the *inner elements* of an array, not instead of an array. and if you really want do it against object, you can always easily convert the object to array. thanks It also supports the __get() method, provided that also __isset() is implemented and returns true for the addressed property. The only BC I can imagine is when an array is populated with a mixed set of objects and arrays; any professional would baulk at the idea, but rules of the jungle are pervasive. Before I merge this, are there any objections to shipping this with 7.0? -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.42 Released
Hello! The PHP development team announces the immediate availability of PHP 5.4.42. Six security-related issues in PHP were fixed in this release, as well as several security issues in bundled sqlite library (CVE-2015-3414, CVE-2015-3415, CVE-2015-3416). All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.42 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on: http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.4.42 Regards, Stas Malyshev PHP 5.4 RM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array dereferencing of scalars
On 12 June 2015 at 00:35, Rowan Collins rowan.coll...@gmail.com wrote: On 11/06/2015 21:22, Chris Wright wrote: I'm inclined to agree that we should have consistency here, and that the current behaviour in a function context is the correct one. A couple of (IMO) good arguments for this: - The function behaviour gives a more explanatory and useful error message - This is definitely a programming error, there is no valid reason to use NULL as a variable name in this manner. It amounts to what many/most other languages would consider to be a null pointer exception or equivalent, and the more useful error message may help track down the error quicker (one might look for a case where the empty string was assigned, instead of looking for a case where it may be NULL). Well, if you were to model it precisely on the function case, the *consistent* behaviour would be to error on any non-string value (e.g. $v = 42; $$v;) but not a string which is an illegal variable name ($v = '42'; $v(); just complains that function 42 doesn't exist, not that it never could). A more useful approach would perhaps be to look at what should be a valid function name, and what should be a valid variable name, and throw an error if dynamic access is used to by-pass either restriction. +1 If anything is to be done, then this should be it - properly abstract the underlying structures so that the lexical/conventional limitations on symbol naming are also imposed by mechanisms that let userland directly manipulate the names of symbols (define(), class_alias() etc). For instance, this doesn't currently complain about the fact that @ is clearly nonsensical as either a function or a variable: $foo = '@'; var_dump($$foo); $foo(); And nor does the empty string, which seems no less obvious a bug than a NULL: $foo = ''; var_dump($$foo); $foo(); -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PR #1325 - array_column() for array of objects
Hi, I've created a PR here: https://github.com/php/php-src/pull/1325 This enhancement allows for properties on objects to work in the same way as arrays for the inner elements of the main array. It also supports the __get() method, provided that also __isset() is implemented and returns true for the addressed property. The only BC I can imagine is when an array is populated with a mixed set of objects and arrays; any professional would baulk at the idea, but rules of the jungle are pervasive. Before I merge this, are there any objections to shipping this with 7.0?
Re: [PHP-DEV] PR #1325 - array_column() for array of objects
Hey: On Fri, Jun 12, 2015 at 9:31 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi, I've created a PR here: https://github.com/php/php-src/pull/1325 This enhancement allows for properties on objects to work in the same way as arrays for the inner elements of the main array. IMO, it is called (array)_column... and if you really want do it against object, you can always easily convert the object to array. thanks It also supports the __get() method, provided that also __isset() is implemented and returns true for the addressed property. The only BC I can imagine is when an array is populated with a mixed set of objects and arrays; any professional would baulk at the idea, but rules of the jungle are pervasive. Before I merge this, are there any objections to shipping this with 7.0? -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Migrating PHP classes to built in namespace
Hi Tony, On Thu, Jun 11, 2015 at 4:37 PM, Tony Marston tonymars...@hotmail.com wrote: Yasuo Ohgaki wrote in message news:CAGa2bXZvuqV4Kwru+wUL-bfTb9_tnv=l16reu-+w+uajx4h...@mail.gmail.com... Hi Jakub, On Thu, Jun 11, 2015 at 7:43 AM, Jakub Kubícek kelerest...@gmail.com wrote: This is weird and ugly what you're fabricating here. The PHP classes should be all in global namespace. I am really against some namespacing of them. It may seems weird if you aren't familiar with languages support this kind of feature. However, you'll find many languages support this or similar. JavaScript is one of them. JavaScript allows to override any functions, for example. It's works like importing other namespace function into root. i.e. Provide different feature with the same name. For long term PHP evolution, having ability to import some namespace into root namespace is great feature. i.e. API/Module version up. We can provide both old and new during migration. Use of namespace is better approach because it may give us super clean global namespace also. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net The fact that other languages have this feature should not be a reason to add it to PHP, especially as it would provide a huge BC break with absolutely no practical, only theoretical, benefits. It does not create huge BC. It's matter of adding a line for namespace or having a default namespace setting. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
