Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP 5.1.0R5 Released »

PHP 5.1.0R5 Released

php.internals

Ilia A.

20 years ago
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

David Zülke

20 years ago
> Ilia Alshanetsky > 5.1 Release Master
Only a master of evil, Darth. [lightsabers clash] SCNR ;) - David

Andreas Korthaus

20 years ago
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

Rasmus Lerdorf

20 years ago
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

Christian Schneider

20 years ago
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

Roman Ivanov

20 years ago
Christian Schneider wrote:
> Please think twice before breaking BC light-heartedly.
Please brake BC completely, and rename everything, and reorder arguments, and replace array() with a(), and replace $this-> with something consise, and replace '->' with '.', and replace '.' with '~'. *smiley*

Oliver Grätz

20 years ago
Roman Ivanov schrieb:
> Christian Schneider wrote: > >>Please think twice before breaking BC light-heartedly. > > > Please brake BC completely, and rename everything, and reorder > arguments, and replace array() with a(), and replace $this-> with > something consise, and replace '->' with '.', and replace '.' with '~'. > *smiley*
Yep. self::$ => @@, $this-> = @ Like in Ruby. (Oh no! Not the nose thing! No!!!) OLLi

Robert Cummings

20 years ago
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. | `------------------------------------------------------------'

Derick Rethans

20 years ago
On Thu, 17 Nov 2005, Robert Cummings wrote:
> 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!
This should fix all occurences (even with PHP 5.1.0): for i in `find . -name \*.php`; do php -l $i; done atleast, if you turn E_STRICT on, with some smart grepping you know in no-time what to change. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Robert Cummings

20 years ago
On Fri, 2005-11-18 at 03:12, Derick Rethans wrote:
> On Thu, 17 Nov 2005, Robert Cummings wrote: > > > 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! > > This should fix all occurences (even with PHP 5.1.0): > > for i in `find . -name \*.php`; do php -l $i; done > > atleast, if you turn E_STRICT on, with some smart grepping you know in > no-time what to change.
That's pretty cool. I always forget about the -l option. Thanks. 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. | `------------------------------------------------------------'

Tim Van Wassenhove

20 years ago
On 2005-11-18, Robert Cummings <robert@interjinn.com> wrote:
> On Fri, 2005-11-18 at 03:12, Derick Rethans wrote: >> On Thu, 17 Nov 2005, Robert Cummings wrote: >> >> > 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! >> >> This should fix all occurences (even with PHP 5.1.0): >> >> for i in `find . -name \*.php`; do php -l $i; done >> >> atleast, if you turn E_STRICT on, with some smart grepping you know in >> no-time what to change. > > That's pretty cool. I always forget about the -l option. Thanks.
Scripts might act weird if you have spaces or other odd chars in your directory names. find . -name '*.php' -exec php -l {} \;
-- Met vriendelijke groeten, Tim Van Wassenhove <http://timvw.madoka.be>

Andreas Korthaus

20 years ago
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

Rasmus Lerdorf

20 years ago
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

Andreas Korthaus

20 years ago
Rasmus Lerdorf wrote:
> 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.
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

Rasmus Lerdorf

20 years ago
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

Andreas Korthaus

20 years ago
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

Ilia A.

20 years ago
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

Robert Cummings

20 years ago
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. | `------------------------------------------------------------'

Robert Cummings

20 years ago
On Thu, 2005-11-17 at 18:51, 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 {}. 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.
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. | `------------------------------------------------------------'

Rasmus Lerdorf

20 years ago
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

Robert Cummings

20 years ago
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. | `------------------------------------------------------------'

Todd Ruth

20 years ago
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

Rasmus Lerdorf

20 years ago
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

Todd Ruth

20 years ago
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

Andi Gutmans

20 years ago
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:

Jani Taskinen

20 years ago
On Thu, 17 Nov 2005, Andi Gutmans wrote:
> 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

Andrei Zmievski

20 years ago
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:

Andreas Korthaus

20 years ago
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

Jani Taskinen

20 years ago
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:

Derick Rethans

20 years ago
On Fri, 18 Nov 2005, Andreas Korthaus 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.
grep won't, but php -l will. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Andreas Korthaus

20 years ago
Derick Rethans wrote:
>> 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. > > grep won't, but php -l will.
That's true. But what about "reducing complexity"? Don't you think it's useful to allow a convention like {} for strings and [] for arrays, so you can be sure what $str{1} means without looking at any context? As Rasmus explained, this can't be enforced, but you still can use a convention in your projects today. I think it's good to increase readability using conventions like that. I'd not drop anything or break any BC, I'd keep this option because having such a convention is very useful when debugging/reading complex scripts. I know that it's not much work to replace {} with [] syntax, but this will decrease readability - that's my only problem. best regards Andreas

Derick Rethans

20 years ago
On Fri, 18 Nov 2005, Andreas Korthaus wrote:
> Derick Rethans wrote: > > > > 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. > > > > grep won't, but php -l will. > > That's true. But what about "reducing complexity"? > > Don't you think it's useful to allow a convention like {} for strings and [] > for arrays, so you can be sure what $str{1} means without looking at any > context?
No. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Hartmut Holzgraefe

20 years ago
Derick Rethans wrote:
>> Don't you think it's useful to allow a convention like {} for strings and [] >> for arrays, so you can be sure what $str{1} means without looking at any >> context? > > No. > > Derick
ok, next stop: "Operator Overloading"? ;)
-- Hartmut Holzgraefe, Senior Support Engineer . MySQL AB, www.mysql.com