[PHP-DEV] a performance question
If anybody should know this for certain, it's core developers, hence my
question here. I'm curious if type certainty requires an extra check, or a
check less.
Which of these is faster?
if ($str === 'abc') { }
if ($str == 'abc') { }
I expect the triple '=' to be faster, but I'd like to be sure.
Thank you,
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] More docs about making PHP extensions?
Hello Roman, http://talks.somabo.de and in general try the source lurke :-) marcus Thursday, November 17, 2005, 9:47:28 AM, you wrote: I've read two tutorials from Sara Golemon (http://zend.com/php/internals/), but it's not enought for me to start writing a real extension. Are there any other docs? API reference? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: a performance question
I'd say if anybody should know this for certain, it's somebody who
bothers to benchmark it:
$ time php -r '$s=abc;for($i=0;$i1000;++$i);'
real0m1.966s
user0m1.634s
sys 0m0.072s
$ time php -r '$s=abc;for($i=0;$i1000;++$i) $s==abc;'
real0m3.974s
user0m3.779s
sys 0m0.062s
$ time php -r '$s=abc;for($i=0;$i1000;++$i) $s===abc;'
real0m2.510s
user0m2.320s
sys 0m0.056s
Ants
Ron Korving wrote:
If anybody should know this for certain, it's core developers, hence my
question here. I'm curious if type certainty requires an extra check, or a
check less.
Which of these is faster?
if ($str === 'abc') { }
if ($str == 'abc') { }
I expect the triple '=' to be faster, but I'd like to be sure.
Thank you,
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging possible Apache php_admin_value crash - Win32 crash trace possible?
Jani, Unfortunately I can't get this to reproduce in my development environment and it's too early for me to switch to 5.1 in production. Michael --- Jani Taskinen [EMAIL PROTECTED] wrote: Do you hit the same issue with using the latest PHP 5.1 snapshot? --Jani On Wed, 16 Nov 2005, Michael Sisolak wrote: I'm trying to debug an issue I'm seeing with PHP 5.0.5 and Apache 2.0.55 (using apache2handler SAPI) running under Windows 2000 Server. I need to set the mssql.max_procs setting to 300. If I change it in php.ini everything works fine and the system is quite stable. To keep all my config changes in one place, however, I wanted to use php_admin_value in httpd.conf instead. As soon as I switched on php_admin_value mssql.max_procs 300, however, Apache2 started resetting about every 10 minutes or so with errors like: [notice] Parent: child process exited with status 3221225477 -- Restarting. I've tested several times and it routinely crashes when I use php_admin_value and doesn't when I stick with just php.ini. Now 3221225477 = 0xC005 = Access Violation so I assume there is some kind of memory corruption happening, but I can't find a way to debug to see what is going on here. Of course it only happens on my production servers and I can't get it to reproduce anywhere else. Does anyone have suggestions about my next step to debug this? I need to find out where the access violation is happening, but Apache eats the error and restarts the process. Is there any magic that can be used to tell Apache to let the error fall though so it can be caught by Dr. Watson or something similar? Or a way to tell PHP to at least record where the violation occurs on the crash? Michael Sisolak [EMAIL PROTECTED] __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging possible Apache php_admin_value crash - Win32 crash trace possible?
Then there is no problem. Next please. :) --Jani On Thu, 17 Nov 2005, Michael Sisolak wrote: Jani, Unfortunately I can't get this to reproduce in my development environment and it's too early for me to switch to 5.1 in production. Michael --- Jani Taskinen [EMAIL PROTECTED] wrote: Do you hit the same issue with using the latest PHP 5.1 snapshot? --Jani On Wed, 16 Nov 2005, Michael Sisolak wrote: I'm trying to debug an issue I'm seeing with PHP 5.0.5 and Apache 2.0.55 (using apache2handler SAPI) running under Windows 2000 Server. I need to set the mssql.max_procs setting to 300. If I change it in php.ini everything works fine and the system is quite stable. To keep all my config changes in one place, however, I wanted to use php_admin_value in httpd.conf instead. As soon as I switched on php_admin_value mssql.max_procs 300, however, Apache2 started resetting about every 10 minutes or so with errors like: [notice] Parent: child process exited with status 3221225477 -- Restarting. I've tested several times and it routinely crashes when I use php_admin_value and doesn't when I stick with just php.ini. Now 3221225477 = 0xC005 = Access Violation so I assume there is some kind of memory corruption happening, but I can't find a way to debug to see what is going on here. Of course it only happens on my production servers and I can't get it to reproduce anywhere else. Does anyone have suggestions about my next step to debug this? I need to find out where the access violation is happening, but Apache eats the error and restarts the process. Is there any magic that can be used to tell Apache to let the error fall though so it can be caught by Dr. Watson or something similar? Or a way to tell PHP to at least record where the violation occurs on the crash? Michael Sisolak [EMAIL PROTECTED] __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging possible Apache php_admin_value crash - Win32 crash trace possible?
Jani, Sorry I wasn't clear - I'm running 5.0.5 in development also. There is something that happens with 5.0.5 + php_admin_value (or at least my specific one) in production that I can't reproduce on another 5.0.5 machine. I assume it has to do with me not being able to accurately reproduce the load and page usage of real users. I can't speak at all to if I do or don't see the same issue in 5.1 yet. Michael --- Jani Taskinen [EMAIL PROTECTED] wrote: Then there is no problem. Next please. :) --Jani On Thu, 17 Nov 2005, Michael Sisolak wrote: Jani, Unfortunately I can't get this to reproduce in my development environment and it's too early for me to switch to 5.1 in production. Michael --- Jani Taskinen [EMAIL PROTECTED] wrote: Do you hit the same issue with using the latest PHP 5.1 snapshot? --Jani On Wed, 16 Nov 2005, Michael Sisolak wrote: I'm trying to debug an issue I'm seeing with PHP 5.0.5 and Apache 2.0.55 (using apache2handler SAPI) running under Windows 2000 Server. I need to set the mssql.max_procs setting to 300. If I change it in php.ini everything works fine and the system is quite stable. To keep all my config changes in one place, however, I wanted to use php_admin_value in httpd.conf instead. As soon as I switched on php_admin_value mssql.max_procs 300, however, Apache2 started resetting about every 10 minutes or so with errors like: [notice] Parent: child process exited with status 3221225477 -- Restarting. I've tested several times and it routinely crashes when I use php_admin_value and doesn't when I stick with just php.ini. Now 3221225477 = 0xC005 = Access Violation so I assume there is some kind of memory corruption happening, but I can't find a way to debug to see what is going on here. Of course it only happens on my production servers and I can't get it to reproduce anywhere else. Does anyone have suggestions about my next step to debug this? I need to find out where the access violation is happening, but Apache eats the error and restarts the process. Is there any magic that can be used to tell Apache to let the error fall though so it can be caught by Dr. Watson or something similar? Or a way to tell PHP to at least record where the violation occurs on the crash? Michael Sisolak [EMAIL PROTECTED] __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging possible Apache php_admin_value crash - Win32 crash trace possible?
I understood you. You don't test 5.1 - then there is not problem with it. 5.1 is the next release. Not 5.0.x. --Jani On Thu, 17 Nov 2005, Michael Sisolak wrote: Jani, Sorry I wasn't clear - I'm running 5.0.5 in development also. There is something that happens with 5.0.5 + php_admin_value (or at least my specific one) in production that I can't reproduce on another 5.0.5 machine. I assume it has to do with me not being able to accurately reproduce the load and page usage of real users. I can't speak at all to if I do or don't see the same issue in 5.1 yet. Michael --- Jani Taskinen [EMAIL PROTECTED] wrote: Then there is no problem. Next please. :) --Jani On Thu, 17 Nov 2005, Michael Sisolak wrote: Jani, Unfortunately I can't get this to reproduce in my development environment and it's too early for me to switch to 5.1 in production. Michael --- Jani Taskinen [EMAIL PROTECTED] wrote: Do you hit the same issue with using the latest PHP 5.1 snapshot? --Jani On Wed, 16 Nov 2005, Michael Sisolak wrote: I'm trying to debug an issue I'm seeing with PHP 5.0.5 and Apache 2.0.55 (using apache2handler SAPI) running under Windows 2000 Server. I need to set the mssql.max_procs setting to 300. If I change it in php.ini everything works fine and the system is quite stable. To keep all my config changes in one place, however, I wanted to use php_admin_value in httpd.conf instead. As soon as I switched on php_admin_value mssql.max_procs 300, however, Apache2 started resetting about every 10 minutes or so with errors like: [notice] Parent: child process exited with status 3221225477 -- Restarting. I've tested several times and it routinely crashes when I use php_admin_value and doesn't when I stick with just php.ini. Now 3221225477 = 0xC005 = Access Violation so I assume there is some kind of memory corruption happening, but I can't find a way to debug to see what is going on here. Of course it only happens on my production servers and I can't get it to reproduce anywhere else. Does anyone have suggestions about my next step to debug this? I need to find out where the access violation is happening, but Apache eats the error and restarts the process. Is there any magic that can be used to tell Apache to let the error fall though so it can be caught by Dr. Watson or something similar? Or a way to tell PHP to at least record where the violation occurs on the crash? Michael Sisolak [EMAIL PROTECTED] __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com -- Give me your money at @ http://pecl.php.net/wishlist.php/sniper Donating money may make me happier and friendlier for a limited period! Death to all 4 letter abbreviations starting with P! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FYI: Inventory Control
FYI, I just turned on inventory control for products 89-93, and gave them 1 units each (this is to make the backend send me mail on signup). -- Sean Coates (php|architect) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FYI: Inventory Control
Sean Coates wrote: FYI, I just turned on inventory control for products 89-93, and gave them 1 units each (this is to make the backend send me mail on signup). Sorry. Wrong list. My apologies. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] More docs about making PHP extensions?
Hi Roman, I was in the same spot 2 weeks ago. Having never programmed in C before and knowing nothing about PHP internals I wasn't sure where to start. The documentation has an appendix in it that covers PHP4 Zend API but a lot is still relevant (or close enough) to begin. Make use of the skeleton extension as a starting point. Sara's articles are good for understanding the ZVAL's usage within PHP. Also, looking at some of the newer extensions like SPL are good starting points to get some of the base concepts down. Good luck, it isn't so hard once you get into it. Bob Silva -Original Message- From: Roman Ivanov [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 12:47 AM To: internals@lists.php.net Subject: [PHP-DEV] More docs about making PHP extensions? I've read two tutorials from Sara Golemon (http://zend.com/php/internals/), but it's not enought for me to start writing a real extension. Are there any other docs? API reference? -- 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] PHP 5.1.0 - sha256() and sha256_file() support
Jacques Marneweck wrote: Are there any chances of getting this implemented in the next releases of PHP 5.0.X and 4.4.X? I don't think there will be any further 5.0.x release. Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1.0 - sha256() and sha256_file() support
Ilia Alshanetsky wrote: You cannot give it an md5 and have it generate you a string with the same md5 hash, so md5 is still relatively safe. http://www.google.com/search?q=md5+hash+lookupstart=0start=0ie=utf-8oe=utf-8client=firefox-arls=org.mozilla:en-US:official -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] dropping curly braces (was: PHP 5.1.0R5 Released)
Hi!
Ilia Alshanetsky wrote:
Once again, I encourage everyone to take the time to try out this RC and
test it against your code or simply run make test.
Works fine for me, but I've a question about the dropped curly braces.
Has there been some public discussion about it recently? I'm sorry if I
have missed it.
Why have curly braces for strings been dropped? Even apart from the fact
that the manual states array-brackets syntax is deprecated as of PHP 4
and AFAIK most people are fine with using curly braces in their scripts
for many years now - what's the idea behind that change?
I think scripts will become more difficult to read, to understand and to
debug.
e.g. think of something like:
$var = myFunction();
// a lot of code
$var[2] = MY_CONSTANT;
// a lot of code
switch ($var[1]) {
// [...]
}
You loose the information whether $var is a string or an array (if only
curly braces were used for strings). That's not a very good example, but
I looked at the phpt tests failing because of the Notice: IMO these
simple files became harder to understand by removing the curly braces.
And if you think of more complex scripts, where the variable
initialisation is far away from the code you try to debug... it makes it
unecessarily hard to understand the code. And don't forget that you
waste more time with reading/understanding old code or code written by
someone else, than writing new code!
Perhaps it's no problem for people coming from C programming which are
probably used to char arrays..., but I'm quite sure that it is more
difficult to learn/understand and USE/READ(!) for the average PHP
programmer. IMO it's very useful to have not the same syntax for arrays
and strings.
Can someone tell me the reason for this decision?
best regards
Andreas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
Very few people converted to using {} so the argument about reading old
code doesn't really hold. If you go and grep through all the public
code out there, pretty much none of it uses {} for character offsets.
And internally there is absolutely no difference between {} and [].
Having two syntaxes for the same thing makes no sense, and getting rid
of [] would break all sorts of stuff. The original reason for the {}
was a technical one to simplify the parser, but the landscape has
changed and that reason no longer exists.
As far a code readability and obviousness goes, I doubt anybody would
guess their way to the $str{5} syntax. If you were new to PHP and you
were going to try to guess how you would get a character offset in a
string, what would your first guess be? Most non-PHP people I have
asked have answered []. Removing the obvious syntax just doesn't make
any sense. The other place {} is used outside of control blocks is in
quoted strings where {$foo{1}} is much uglier than {$foo[1]}.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Rasmus Lerdorf wrote:
Very few people converted to using {} so the argument about reading old
code doesn't really hold. If you go and grep through all the public
code out there, pretty much none of it uses {} for character offsets.
I'd like to cite Andi here:
Regarding BC breakage. I'm not saying we shouldn't break BC in some
cases, but in many cases, there's no big advantage (except for some
people's warm and fuzzy feelings), and it can cause a lot of heart
aches and disruption in PHP use. Migration is very important.
See http://news.php.net/php.internals/19415 for the full post.
Please think twice before breaking BC light-heartedly.
Thanks,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
On Thu, 2005-11-17 at 16:42, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
Very few people converted to using {} so the argument about reading old
Ugh, so those of us that did are going to have to comb back through our
code and revert after following the original suggestion. UGH!
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Hi Rasmus!
Rasmus Lerdorf wrote:
Very few people converted to using {} so the argument about reading old
code doesn't really hold.
I can't belive that most of the code today is based on =PHP3 code. I'm
not talking about such PHP3 based code. I'm talking about code, you
wrote 1 year ago and did not touch for 10 months. Or code you have to
debug which someone else wrote.
If you go and grep through all the public
code out there, pretty much none of it uses {} for character offsets.
That's the problem - also grep does not know if [] is used for arrays or
stings. That's the same for programmers, it's often not easy to conclude
from context - that's my point.
Having two syntaxes for the same thing makes no sense, and getting rid
of [] would break all sorts of stuff.
Do you think it would break more stuff than getting rid of {}? How do
you know? grep definitely can't help you here.
The original reason for the {}
was a technical one to simplify the parser, but the landscape has
changed and that reason no longer exists.
But [] has been marked deprecated in favour of {} for 5 years now.
Netcraft finds 10 times more php-domains today than 5 years ago.
As far a code readability and obviousness goes, I doubt anybody would
guess their way to the $str{5} syntax.
But you know without understanding of any context, that it's the 6th
character of the string $str. When you see $var[5], it could be the
6th character of a string, or an element of an array... and what about
the value? You can't be sure that it's a string with length 1, it also
could be another array, an object, a string with length 4711...
That increases complexity and decreases readability.
If you were new to PHP and you
were going to try to guess how you would get a character offset in a
string, what would your first guess be? Most non-PHP people I have
asked have answered [].
Hm, most people I can think of would seach the manual for a string
function, and not even think of syntax like {} or []. Some day I found
{} syntax in the manual, saw that I could use [] too, but which is
deprecated. {} was a very straightforward syntax in my eyes (at that
time). If you want to use PHP, you have to know the manual anyway, so I
don't think this is a big advantage.
Removing the obvious syntax just doesn't make
any sense. The other place {} is used outside of control blocks is in
quoted strings where {$foo{1}} is much uglier than {$foo[1]}.
Yes that's a disadvantage. But one of my most important goals when
writing scripts (in a major project) is to reduce complexity and make
scripts as easy to understand as possible. And PHP makes a good job
here. But I think the {} - [] change will reduce readability of
scripts, because both programmers and grep can't differ arrays from
strings using the [] syntax anymore.
However, thanks a lot for your time/explanation!
best regards
Andreas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Andreas Korthaus wrote:
As far a code readability and obviousness goes, I doubt anybody would
guess their way to the $str{5} syntax.
But you know without understanding of any context, that it's the 6th
character of the string $str. When you see $var[5], it could be the
6th character of a string, or an element of an array... and what about
the value? You can't be sure that it's a string with length 1, it also
could be another array, an object, a string with length 4711...
That increases complexity and decreases readability.
Your argument falls apart there. Try it:
$a = array(ab,cd,ef);
echo $a{2};
Guess what that prints? {} has nothing to do with strings. They are
100% equivalent to [] and as such add nothing to clarity.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility to
have a convention like [] for arrays and {} for strings.
If I could decide I would drop {} for arrays and [] for strings, but I
fear I will not be asked to decide... ;-)
And you are willing to break just about every application out there for
this? There are millions of lines of code that uses [] for string
offsets.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility to
have a convention like [] for arrays and {} for strings.
If I could decide I would drop {} for arrays and [] for strings, but I
fear I will not be asked to decide... ;-)
You may think that {} and [] are different, but in reality same code
deals with both. Having two constructs for the same behavior is silly
and leads to confusing, hard to read code. Especially so when you
consider the fact {} has another meaning that is completely different.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.1.0R6 Released
Once more unto the breach. One of the issues that was open until now was a regression in the behavior of Apache 2 sapi on non-linux systems. The problem was finally discovered and resolved, so if you've experienced crashes or weird behavior with Apache 2 and PHP 5.1/4.4.1, please give this RC a shot. The second reason for the RC is the update of the new parameter parsing API used by large number of PHP functions, such as date(). Until this RC, handling of integer values was very strict, rejecting all non-well formed numeric values when a function expected a number. As of now the checks have been relaxed (as was the case in old API) and non-well formed ints like 123 and 123 are once again supported. However, to promote code safety and input validation the function will emit E_NOTICE when they are encountered. http://downloads.php.net/ilia/php-5.1.0RC6.tar.bz2 fba81c7832fc254722b012adb10f5914 http://downloads.php.net/ilia/php-5.1.0RC6.tar.gz ae7a81d10bc93bc1426d489ee8fc1196 The Windows binaries will be available shortly from http://downloads.php.net/ilia/ as well. Once again, I encourage everyone to take the time to try out this RC and test it against your code or simply run make test. Ilia Alshanetsky 5.1 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility to
have a convention like [] for arrays and {} for strings.
If I could decide I would drop {} for arrays and [] for strings, but I
fear I will not be asked to decide... ;-)
You may think that {} and [] are different, but in reality same code
deals with both. Having two constructs for the same behavior is silly
and leads to confusing, hard to read code. Especially so when you
consider the fact {} has another meaning that is completely different.
That should have been considered before everyone was told that [] was
deprecated for strings in favour of {}. Dropping support for string
access via {} is akin to slapping those who followed the lead. Once
bitten, twice shy. I don't see support for ? being dropped anytime, yet
it falls under the exact same argument. But maybe there's a trend
emerging here, and in fact ?php will be deprecated in the near future.
It's a tough call since credibility is rapidly swirling down the toilet.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Robert Cummings wrote:
On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility to
have a convention like [] for arrays and {} for strings.
If I could decide I would drop {} for arrays and [] for strings, but I
fear I will not be asked to decide... ;-)
You may think that {} and [] are different, but in reality same code
deals with both. Having two constructs for the same behavior is silly
and leads to confusing, hard to read code. Especially so when you
consider the fact {} has another meaning that is completely different.
That should have been considered before everyone was told that [] was
deprecated for strings in favour of {}.
Right, that was a mistake which we are fixing now. Removing [] doesn't
seem to be a viable option, so rather than continue to tell people to
stop using [] since it is never going to go away, the main decision here
was to undeprecate []. Whether we will eventually remove {} or not
remains to be seen. The initial idea was to try to remove it in PHP6
and in order to help people easily find where these are used, add an
E_STRICT for it in PHP 5.1.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
On Thu, 2005-11-17 at 19:05, Rasmus Lerdorf wrote:
Robert Cummings wrote:
On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility to
have a convention like [] for arrays and {} for strings.
If I could decide I would drop {} for arrays and [] for strings, but I
fear I will not be asked to decide... ;-)
You may think that {} and [] are different, but in reality same code
deals with both. Having two constructs for the same behavior is silly
and leads to confusing, hard to read code. Especially so when you
consider the fact {} has another meaning that is completely different.
That should have been considered before everyone was told that [] was
deprecated for strings in favour of {}.
Right, that was a mistake which we are fixing now. Removing [] doesn't
seem to be a viable option, so rather than continue to tell people to
stop using [] since it is never going to go away, the main decision here
was to undeprecate []. Whether we will eventually remove {} or not
remains to be seen. The initial idea was to try to remove it in PHP6
and in order to help people easily find where these are used, add an
E_STRICT for it in PHP 5.1.
Ok, then that's not so bad. PHP6 is undoubtedly some ways off giving
adequate time to revert such code. I hate that sneaky E_STRICT stuff :)
BTW, I'm with the other guys on the convention argument too. I find that
reading my code now that I've gotten into the habit of always using {}
for strings, that I can easily pick out where my string indexing is
happening versus array indexing.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Rasmus Lerdorf wrote:
And you are willing to break just about every application out there for
this?
I didn't know how many applications use [] with strings. I only know a
lot of applications using {}. The point is not breaking existing apps,
but destroy a sensable convention, which is used a lot, and which is
quite useful to increase readability of code as described in my other
postings.
I have no problem with changing my code if BC breaks, but in this case
I'd be sad to loose the useful convention [] for arrays and {} for
strings.
best regards
Andreas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Upgrading php
I'd been ignoring the curly braces thread, but then I grepped my code and ... sure enough, I have curly braces that are used to index into strings. I don't care about this philosophically, but it makes me wonder about upgrade tools. I know I shouldn't ask this without volunteering to do it myself, but when a version of php comes out that makes such a change, is there any chance of having a tool that updates the code available at the same time? It seems to me that nothing understands php user code better than the core php code, so perhaps a tool could be written that uses the guts of php as a base. I suppose there are some IDEs that could do the job as well. Sadly, I still use vi, but I bet if something were written for emacs or eclipse, most people (even me) could learn to use it. I'm dreading going to php5. I hear that to avoid warnings/notices I'll need to convert a bunch of vars to publics. I'll need to wrap my get_classs with strtolowers. etc. It would be so wonderful to throw all my code at a tool that would change everything that can be easily changed and give me a list of spots I need to look at manually. A lot of the changes don't take an overwhelming amount of time to do myself, but when you think about the thousands of users all doing the same conversions, it just makes sense for there to be a tool. It might also have the side benefit of reducing long threads about breaking old code. Perhaps this already exists and I've missed it. Perhaps it will never exist because it isn't enough fun to write. Just an idea... - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading php
Todd Ruth wrote: I'd been ignoring the curly braces thread, but then I grepped my code and ... sure enough, I have curly braces that are used to index into strings. I don't care about this philosophically, but it makes me wonder about upgrade tools. I know I shouldn't ask this without volunteering to do it myself, but when a version of php comes out that makes such a change, is there any chance of having a tool that updates the code available at the same time? It seems to me that nothing understands php user code better than the core php code, so perhaps a tool could be written that uses the guts of php as a base. I suppose there are some IDEs that could do the job as well. Sadly, I still use vi, but I bet if something were written for emacs or eclipse, most people (even me) could learn to use it. I'm dreading going to php5. I hear that to avoid warnings/notices I'll need to convert a bunch of vars to publics. I'll need to wrap my get_classs with strtolowers. etc. It would be so wonderful to throw all my code at a tool that would change everything that can be easily changed and give me a list of spots I need to look at manually. A lot of the changes don't take an overwhelming amount of time to do myself, but when you think about the thousands of users all doing the same conversions, it just makes sense for there to be a tool. It might also have the side benefit of reducing long threads about breaking old code. Perhaps this already exists and I've missed it. Perhaps it will never exist because it isn't enough fun to write. Just an idea... This is what the E_STRICT messages are for. If you turn them on (in PHP 5) you will get very specific messages about language-level issues in your code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading php
Hi Todd, I'm hoping that in future we can provide better tools for upgrading in between versions. Both from an auto-conversion perspective and just scanning the code statically and printing out warnings on what code to check. Coupled with better upgrading docs I think we'd improve the current situation significantly. Main problem is that currently there haven't been the people to get it done. We did write some upgrading docs for 5.1 (not sure if they made it into the RC but they can always make it to the site), but this whole area needs a lot more work and help. Andi At 04:44 PM 11/17/2005, Todd Ruth wrote: I'd been ignoring the curly braces thread, but then I grepped my code and ... sure enough, I have curly braces that are used to index into strings. I don't care about this philosophically, but it makes me wonder about upgrade tools. I know I shouldn't ask this without volunteering to do it myself, but when a version of php comes out that makes such a change, is there any chance of having a tool that updates the code available at the same time? It seems to me that nothing understands php user code better than the core php code, so perhaps a tool could be written that uses the guts of php as a base. I suppose there are some IDEs that could do the job as well. Sadly, I still use vi, but I bet if something were written for emacs or eclipse, most people (even me) could learn to use it. I'm dreading going to php5. I hear that to avoid warnings/notices I'll need to convert a bunch of vars to publics. I'll need to wrap my get_classs with strtolowers. etc. It would be so wonderful to throw all my code at a tool that would change everything that can be easily changed and give me a list of spots I need to look at manually. A lot of the changes don't take an overwhelming amount of time to do myself, but when you think about the thousands of users all doing the same conversions, it just makes sense for there to be a tool. It might also have the side benefit of reducing long threads about breaking old code. Perhaps this already exists and I've missed it. Perhaps it will never exist because it isn't enough fun to write. Just an idea... - Todd -- 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] Upgrading php
On Thu, 2005-11-17 at 16:47 -0800, Rasmus Lerdorf wrote: Todd Ruth wrote: ... It would be so wonderful to throw all my code at a tool that would change everything that can be easily changed and give me a list of spots I need to look at manually. A lot of the changes don't take an overwhelming amount of time to do myself, but when you think about the thousands of users all doing the same conversions, it just makes sense for there to be a tool. It might also have the side benefit of reducing long threads about breaking old code. Perhaps this already exists and I've missed it. Perhaps it will never exist because it isn't enough fun to write. Just an idea... This is what the E_STRICT messages are for. If you turn them on (in PHP 5) you will get very specific messages about language-level issues in your code. -Rasmus I appreciate those messages. There are probably things that come up at runtime for which the E_STRICT messages are the only good option. (My guess is that it would be too much trouble to make a version of php that rewrites my source code on the fly. ;) ) On the other hand, my current upgrade approach is: - go to the new version - try to use all of my code paths and copy and paste the notices to a file - sed the file into a list of vi commands that take me to every line that generated a message - after recognizing the pattern for the simple fixes, define macros to do most of the work - Try to maintain consciousness while applying the macros over and over again. If I weren't nearly the last person on the planet to upgrade, it would be useful for me to at least post my vi macros somewhere. Perhaps if other people are following a similar approach, they could post whatever they use to get them over hurdles. The hope in my original email is that if php is clever enough to give me a message, it might be clever enough to just make the change too. I appologize again for bringing this up without providing any tools. I just wanted to make sure it was considered. Maybe there could be a spot on php.net where people are encouraged to post (or at least post links to) what helped them get through php transitions. Thanks again, Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
How do you know this? Have you conducted polls?
-Andrei
On Nov 17, 2005, at 3:19 PM, Jevon Wright wrote:
Is there anything wrong with having a convention for character
access of strings? Most PHP programmers see {} as string access and
[] as array access - sure, they might be functionally identical,
but its the convention which is important.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
You will break many more scripts by dropping [] for strings than the
other way around. Do you agree?
-Andrei
On Nov 17, 2005, at 3:26 PM, Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility
to have a convention like [] for arrays and {} for strings.
If I could decide I would drop {} for arrays and [] for strings,
but I fear I will not be asked to decide... ;-)
Best regards
Andreas
--
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
[PHP-DEV] reflection ext
Marcus,
are you going to be using any module globals in the extension?
I had to remove the code for it to get it to build on windows - patached
attached.
Though it does build fine if you do define some.
Rob
Index: php_reflection.c
===
RCS file: /repository/php-src/ext/reflection/php_reflection.c,v
retrieving revision 1.190
diff -u -r1.190 php_reflection.c
--- php_reflection.c17 Nov 2005 22:59:38 - 1.190
+++ php_reflection.c18 Nov 2005 03:14:00 -
@@ -50,18 +50,6 @@
PHPAPI zend_class_entry *reflection_property_ptr;
PHPAPI zend_class_entry *reflection_extension_ptr;
-ZEND_BEGIN_MODULE_GLOBALS(reflection)
-ZEND_END_MODULE_GLOBALS(reflection)
-
-#ifdef ZTS
-# define REFLECTION_G(v) \
- TSRMG(reflection_globals_id, zend_reflection_globals*, v)
-extern int reflection_globals_id;
-#else
-# define REFLECTION_G(v) (reflection_globals.v)
-extern zend_reflection_globals reflectionglobals;
-#endif
-
#ifdef COMPILE_DL_REFLECTION
ZEND_GET_MODULE(reflection)
#endif
@@ -4184,17 +4172,10 @@
}
/* }}} */
-static void reflection_init_globals(zend_reflection_globals *globals) /* {{{ */
-{
- /* Initialize your global struct */
-} /* }}} */
-
PHP_MINIT_FUNCTION(reflection) /* {{{ */
{
zend_class_entry _reflection_entry;
- ZEND_INIT_MODULE_GLOBALS(reflection, reflection_init_globals, NULL);
-
zend_std_obj_handlers = zend_get_std_object_handlers();
memcpy(reflection_object_handlers, zend_get_std_object_handlers(),
sizeof(zend_object_handlers));
reflection_object_handlers.clone_obj = NULL;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Hi Andrei!
Andrei Zmievski wrote:
You will break many more scripts by dropping [] for strings than the
other way around. Do you agree?
Until tonight I was sure that only a few projects still use the []
syntax which is depreciated for 5 years.
But if some of you don't think so I'm probably wrong. For me it's more
important to have the possibility to use a convention (like $arrays[],
$strings{}) in a project, not to drop something. Looks like if I will
loose this possibility soon.
best regards
Andreas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading php
Todd Ruth wrote: The hope in my original email is that if php is clever enough to give me a message, it might be clever enough to just make the change too. A scripting language is not a spell checker, you can forget about it auto-correcting your code. The E_STRICT/E_NOTICE messages are emitted to notify the developer something is not quite right, so that they can make the appropriate changes to future proof their code. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Upgrade notes for PHP 5.1 - 4th draft
I know it's 50-50 at least one of these items will change before my mail
reaches the list, but here's version 4 for your perusal.
Note: I have type hints for arrays down as being 'still under discussion' -
this isn't actually ready to go.
I've thrown out new features such as the Zend VM execution modes (and am
still debating whether to throw out default class type hints) because they
should be covered elsewhere, and I haven't done anything about replaced
extensions (e.g. w32api = ffi) because they should be covered in the
manual. I've some fear of terrifying would-be upgraders with an
unnecessarily long list here :)
Please be critical.
Thanks,
- Steph
UPGRADE NOTES - PHP 5.1
1. Changes in reference handling
a. Overview
b. Code that worked under PHP 4.3, but now fails
c. Code that was valid under PHP 4.3, but now throws an error
d. Code that failed under PHP 4.3, but now works
e. Code that 'should have worked' under PHP 5.0
f. Warnings that came and went
2. Reading []
3. String offset access
4. instanceof, is_a(), is_subclass_of(), catch
5. Abstract private methods
6. Type hints and NULL* STILL UNDER DISCUSSION (for arrays)
7. Integer values in function parameters
8. General extension-related changes in PHP 5.1
9. Date/time support
10. Changes in database support
a. PDO overview
b. Changes in MySQL support
c. Changes in SQLite support
11. Further migration information
===
1. Changes in reference handling
1a. Overview
From the PHP script writer's point of view, the change most likely to impact
legacy code is in the way that references are handled in all PHP versions
post-dating the PHP 4.4.0 release.
Until and including PHP 4.3, it was possible to send, assign or return variables
by reference that should really be returned by value, such as a constant, a
temporary value (e.g. the result of an expression), or the result of a function
that had itself been returned by value, as here:
?php
$foo = 123;
function return_value() {
global $foo;
return $foo;
}
$bar = return_value();
?
Although this code would usually work as expected under PHP 4.3, in the general
case the result is undefined. The Zend Engine could not act correctly on these
values as references. This bug could and did lead to various hard-to-reproduce
memory corruption problems, particularly where the code base was large.
In PHP 4.4.0, PHP 5.0.4 and all subsequent PHP releases, the Engine was fixed
to 'know' when the reference operation is being used on a value that should
not be referenced. The actual value is now used in such cases, and a warning
is emitted. The warning takes the form of an E_NOTICE in PHP 4.4.0 and up,
and E_STRICT in PHP 5.0.4 and up.
Code that could potentially produce memory corruption can no longer do so.
However, some legacy code might work differently as a result.
1b. Code that worked under PHP 4.3, but now fails
=
?php
function func($arraykey) {
return $arraykey; // function returns by value!
}
$array = array('a', 'b', 'c');
foreach (array_keys($array) as $key) {
$y = func($array[$key]);
$z[] = $y;
}
var_dump($z);
?
Running the above script under any version of PHP that pre-dates the reference
fix would produce this output:
array(3) {
[0]=
string(1) a
[1]=
string(1) b
[2]=
string(1) c
}
Following the reference fix, the same code would result in:
array(3) {
[0]=
string(1) c
[1]=
string(1) c
[2]=
string(1) c
}
This is because, following the changes, func() assigns by value. The value
of $y is re-assigned, and reference-binding is preserved from $z. Prior
to the fix, the value was assigned by reference, leading $y to be
re-bound on each assignment. The attempt to bind to a temporary value
by reference was the cause of the memory corruption.
Such code can be made to work identically in both the pre-fix and the
post-fix PHP versions. The signature of func() can be altered to return
by reference, or the reference assignment can be removed from the result
of func().
?php
function func() {
return 'function return';
}
$x = 'original value';
$y = $x;
$y = func();
echo $x;
?
In PHP 4.3 $x would be 'original value', whereas after the changes it would
be 'function return' - remember that where the function does not return by
reference, the reference assignment is converted to a regular assignment.
Again, this can be brought to a common base, either by forcing func() to
return by reference or by eliminating the by-reference assignment.
1c. Code that was valid under PHP 4.3, but now throws an error
==
?php
class Foo {
function getThis() {
return $this;
}
function destroyThis() {
$baz = $this-getThis();
}
}
$bar = new Foo();
$bar-destroyThis();
RE: [PHP-DEV] Upgrade notes for PHP 5.1 - 4th draft
Hi Steph, Maybe in section 4, explain what the result of the change is. You explain what was wrong in the past, but don't really cover what the new behavior is. Bob -Original Message- From: Steph Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 9:11 PM To: internals Subject: [PHP-DEV] Upgrade notes for PHP 5.1 - 4th draft I know it's 50-50 at least one of these items will change before my mail reaches the list, but here's version 4 for your perusal. Note: I have type hints for arrays down as being 'still under discussion' - this isn't actually ready to go. I've thrown out new features such as the Zend VM execution modes (and am still debating whether to throw out default class type hints) because they should be covered elsewhere, and I haven't done anything about replaced extensions (e.g. w32api = ffi) because they should be covered in the manual. I've some fear of terrifying would-be upgraders with an unnecessarily long list here :) Please be critical. Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection ext
Hello Rob, we can define a dummy in it. I thought that some compilter don't like empty structs. marcus Friday, November 18, 2005, 4:18:51 AM, you wrote: Marcus, are you going to be using any module globals in the extension? I had to remove the code for it to get it to build on windows - patached attached. Though it does build fine if you do define some. Rob Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Just a friendly note from my PHP user side:
We had 2 places where {} where used for accessing string.
Took me 10 seconds to remove those with the help of
the nice E_STRICT error. (filename, linenumber)
--Jani
On Thu, 17 Nov 2005, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
As far a code readability and obviousness goes, I doubt anybody would guess
their way to the $str{5} syntax.
But you know without understanding of any context, that it's the 6th
character of the string $str. When you see $var[5], it could be the 6th
character of a string, or an element of an array... and what about the
value? You can't be sure that it's a string with length 1, it also could be
another array, an object, a string with length 4711...
That increases complexity and decreases readability.
Your argument falls apart there. Try it:
$a = array(ab,cd,ef);
echo $a{2};
Guess what that prints? {} has nothing to do with strings. They are 100%
equivalent to [] and as such add nothing to clarity.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection ext
Yes, but if you're not planning to have any module globals, wouldn't it be better to just nuke the lines? --Jani On Fri, 18 Nov 2005, Marcus Boerger wrote: Hello Rob, we can define a dummy in it. I thought that some compilter don't like empty structs. marcus Friday, November 18, 2005, 4:18:51 AM, you wrote: Marcus, are you going to be using any module globals in the extension? I had to remove the code for it to get it to build on windows - patached attached. Though it does build fine if you do define some. Rob Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
