# PHP 5.1.0R5 Released - Thread: https://externals.io/message/20066 - Original archive: https://news-web.php.net/php.internals/20066 - Started by Ilia Alshanetsky on 2005-11-16T15:40:58+00:00 - Messages: 43 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/20066.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #20066 — Ilia Alshanetsky — 2005-11-16T15:40:58+00:00 URL: https://externals.io/message/20066#20066 Unfortunately several issues discovered in RC4 and the fixes were sufficiently complex to warrant another release candidate. So here goes the fifth and hopefully the final RC of 5.1.0. You can download the source packages from here: http://downloads.php.net/ilia/php-5.1.0RC5.tar.bz2 8a6d9b78203a251f2e095ee602b078b1 http://downloads.php.net/ilia/php-5.1.0RC5.tar.gz 8daab7af7e742fc14800e2a037f493b1 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 --- ## #20067 — dz@bitxtender.com — 2005-11-16T16:10:29+00:00 URL: https://externals.io/message/20066#20067 · In reply to: #20066 > Ilia Alshanetsky > 5.1 Release Master Only a master of evil, Darth. [lightsabers clash] SCNR ;) - David --- ## #20102 — Andreas Korthaus — 2005-11-17T21:31:32+00:00 URL: https://externals.io/message/20066#20102 · In reply to: #20066 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 --- ## #20103 — Rasmus Lerdorf — 2005-11-17T21:42:27+00:00 URL: https://externals.io/message/20066#20103 · In reply to: #20102 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 --- ## #20104 — Christian Schneider — 2005-11-17T22:30:16+00:00 URL: https://externals.io/message/20066#20104 · In reply to: #20103 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 for the full post. Please think twice before breaking BC light-heartedly. Thanks, - Chris --- ## #20106 — Robert Cummings — 2005-11-17T23:04:45+00:00 URL: https://externals.io/message/20066#20106 · In reply to: #20103 > Andreas Korthaus wrote: > > > […] > > 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. | `------------------------------------------------------------' --- ## #20107 — Andreas Korthaus — 2005-11-17T23:06:48+00:00 URL: https://externals.io/message/20066#20107 · In reply to: #20103 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 --- ## #20108 — Rasmus Lerdorf — 2005-11-17T23:11:30+00:00 URL: https://externals.io/message/20066#20108 · In reply to: #20107 Andreas Korthaus wrote: > > […] > > 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 --- ## #20110 — Andreas Korthaus — 2005-11-17T23:26:47+00:00 URL: https://externals.io/message/20066#20110 · In reply to: #20108 Rasmus Lerdorf wrote: > Andreas Korthaus wrote: > > […] > > 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. 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 --- ## #20111 — Rasmus Lerdorf — 2005-11-17T23:31:43+00:00 URL: https://externals.io/message/20066#20111 · In reply to: #20110 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 --- ## #20112 — Ilia Alshanetsky — 2005-11-17T23:33:53+00:00 URL: https://externals.io/message/20066#20112 · In reply to: #20110 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 --- ## #20114 — Robert Cummings — 2005-11-17T23:51:40+00:00 URL: https://externals.io/message/20066#20114 · In reply to: #20112 > Andreas Korthaus wrote: > > […] > > 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 > > […] > > 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 it falls under the exact same argument. But maybe there's a trend > emerging here, and in fact It's a tough call since credibility is rapidly swirling down the toilet. I just re-read what I posted, and it's a bit meaner sounding than I intended, but I'm sure you can understand the mounting frustration :| 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. | `------------------------------------------------------------' --- ## #20116 — Rasmus Lerdorf — 2005-11-18T00:05:06+00:00 URL: https://externals.io/message/20066#20116 · In reply to: #20114 Robert Cummings wrote: > > > […] > > 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 --- ## #20117 — Robert Cummings — 2005-11-18T00:17:30+00:00 URL: https://externals.io/message/20066#20117 · In reply to: #20116 > Robert Cummings wrote: > > […] > > 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. | `------------------------------------------------------------' --- ## #20118 — Andreas Korthaus — 2005-11-18T00:27:11+00:00 URL: https://externals.io/message/20066#20118 · In reply to: #20111 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 --- ## #20119 — Todd Ruth — 2005-11-18T00:44:26+00:00 URL: https://externals.io/message/20066#20119 · In reply to: #20112 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 "var"s to "public"s. I'll need to wrap my "get_class"s with "strtolower"s. 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 --- ## #20120 — Rasmus Lerdorf — 2005-11-18T00:47:02+00:00 URL: https://externals.io/message/20066#20120 · In reply to: #20119 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 "var"s to "public"s. I'll need to > wrap my "get_class"s with "strtolower"s. 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 --- ## #20121 — Andi Gutmans — 2005-11-18T00:54:05+00:00 URL: https://externals.io/message/20066#20121 · In reply to: #20119 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 "var"s to "public"s. I'll need to >wrap my "get_class"s with "strtolower"s. 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 --- ## #20122 — Todd Ruth — 2005-11-18T01:08:40+00:00 URL: https://externals.io/message/20066#20122 · In reply to: #20120 > Todd Ruth wrote: ... > > […] > > 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 --- ## #20124 — Andrei Zmievski — 2005-11-18T01:38:26+00:00 URL: https://externals.io/message/20066#20124 · In reply to: #20110 You will break many more scripts by dropping [] for strings than the other way around. Do you agree? -Andrei > 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 --- ## #20126 — Andreas Korthaus — 2005-11-18T03:58:07+00:00 URL: https://externals.io/message/20066#20126 · In reply to: #20124 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 --- ## #20127 — Ilia Alshanetsky — 2005-11-18T04:28:33+00:00 URL: https://externals.io/message/20066#20127 · In reply to: #20122 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 --- ## #20131 — Jani Taskinen — 2005-11-18T07:52:11+00:00 URL: https://externals.io/message/20066#20131 · In reply to: #20108 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 > > Andreas Korthaus wrote: > > […] > > 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 --- ## #20133 — Jani Taskinen — 2005-11-18T08:06:43+00:00 URL: https://externals.io/message/20066#20133 · In reply to: #20121 > 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. We already have the scanner: # php -derror_reporting=4095 -l script_to_check.php Strict Standards: Usage of {} to access string offsets is deprecated and will be removed in PHP 6 in t.php on line 6 No syntax errors detected in t.php With a simple shell script you can create a list of files having any errors/warnings/notices/strict.. :) At work we use a syntax checker script run whenever we commit files to our CVS repository to catch any errors early..this reminded me to fix that script to catch notices and such too. :) --Jani --- Next page: https://externals.io/message/20066.md?page=2