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
Ilia Alshanetsky
5.1 Release Master
Only a master of evil, Darth. [lightsabers clash]
SCNR ;)
- David
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
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
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
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
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
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. |
`------------------------------------------------------------'
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
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; doneatleast, if you turn
E_STRICTon, 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. |
`------------------------------------------------------------'
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; doneatleast, if you turn
E_STRICTon, 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
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
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
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
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
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
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
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. |
`------------------------------------------------------------'
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. |
`------------------------------------------------------------'
Robert Cummings 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 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_STRICTfor 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. |
`------------------------------------------------------------'
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
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
- you will get very specific messages about language-level issues in
your code.
-Rasmus
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_STRICTmessages are for. If you turn them on (in PHP
- 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
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
Ilia Alshanetsky wrote:
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.
Sounds like a feature someone could stick into their IDE or bytecode
cache. However providing scripts to clean up language changes as a php
script sounds like something that could be done if someone finds the time.
For now it really sounds like a great business opportunity to me :-)
regards,
Lukas
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
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
Jani, I'm going to slip that into the upgrade notes - I wasn't aware you
could do this 'til now either!
----- Original Message -----
From: "Jani Taskinen" sniper@iki.fi
To: "Andi Gutmans" andi@zend.com
Cc: truth@proposaltech.com; internals@lists.php.net
Sent: Friday, November 18, 2005 8:06 AM
Subject: Re: [PHP-DEV] Upgrading php
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.phpWith 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
Jani, I'm going to slip that into the upgrade notes - I wasn't aware you
could do this 'til now either!----- Original Message -----
From: "Jani Taskinen" sniper@iki.fi
To: "Andi Gutmans" andi@zend.com
Cc: truth@proposaltech.com; internals@lists.php.net
Sent: Friday, November 18, 2005 8:06 AM
Subject: Re: [PHP-DEV] Upgrading phpI'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.phpWith 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--
--
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!
The shell script we use here at work can be found here:
http://www.php.net/~jani/patches/syntax_check.sh.txt
We have this line in our CVSROOT/commitinfo file:
ALL $CVSROOT/CVSROOT/syntax_check.sh %r/%p %s
--Jani
Jani, I'm going to slip that into the upgrade notes - I wasn't aware you
could do this 'til now either!----- Original Message -----
From: "Jani Taskinen" sniper@iki.fi
To: "Andi Gutmans" andi@zend.com
Cc: truth@proposaltech.com; internals@lists.php.net
Sent: Friday, November 18, 2005 8:06 AM
Subject: Re: [PHP-DEV] Upgrading phpI'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.phpWith 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--
--
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!
Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6 comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.
We had something similar to (a) and (b) when we moved people from
PHP/FI 2 to PHP 3 as there were some significant differences. That
said, it's not always simple because you might need to have to reuse
the scanner/parser and a simple PHP script might not be enough.
Hopefully, as we get closer to PHP 6 there will be people who have
time to invest in this.
Most important thing at this point, is to keep the upgrading docs
(which will be first released with 5.1) in sync with the changes, so
that when the time comes with PHP 6, it'll be easy to translate the
docs to such a script, without forgetting half the stuff that was changed.
Andi
At 12:06 AM 11/18/2005, Jani Taskinen 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.phpWith 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
What about using http://pear.php.net/package/PHP_CompatInfo as a
basis? It seemed to do a pretty good job last time I ran it...
- Eric
--
Eric Coleman
http://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176
Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6
comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.We had something similar to (a) and (b) when we moved people from
PHP/FI 2 to PHP 3 as there were some significant differences. That
said, it's not always simple because you might need to have to
reuse the scanner/parser and a simple PHP script might not be enough.Hopefully, as we get closer to PHP 6 there will be people who have
time to invest in this.
Most important thing at this point, is to keep the upgrading docs
(which will be first released with 5.1) in sync with the changes,
so that when the time comes with PHP 6, it'll be easy to translate
the docs to such a script, without forgetting half the stuff that
was changed.Andi
At 12:06 AM 11/18/2005, Jani Taskinen 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.phpWith 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 commitfiles
to our CVS repository to catch any errors early..this reminded
me to
fix that script to catch notices and such too. :)--Jani
Current release: 1.0.0 (stable) was released on 2005-03-15
That means it's not up to date enough to help with 5.0 -> 5.1 upgrades...
----- Original Message -----
From: "Eric Coleman" eric@aplosmedia.com
To: "Andi Gutmans" andi@zend.com
Cc: "Jani Taskinen" sniper@iki.fi; truth@proposaltech.com;
internals@lists.php.net
Sent: Sunday, November 20, 2005 3:24 AM
Subject: Re: [PHP-DEV] Upgrading php
What about using http://pear.php.net/package/PHP_CompatInfo as a
basis? It seemed to do a pretty good job last time I ran it...
- Eric
--
Eric Colemanhttp://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6
comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.We had something similar to (a) and (b) when we moved people from
PHP/FI 2 to PHP 3 as there were some significant differences. That
said, it's not always simple because you might need to have to
reuse the scanner/parser and a simple PHP script might not be enough.Hopefully, as we get closer to PHP 6 there will be people who have
time to invest in this.
Most important thing at this point, is to keep the upgrading docs
(which will be first released with 5.1) in sync with the changes,
so that when the time comes with PHP 6, it'll be easy to translate
the docs to such a script, without forgetting half the stuff that
was changed.Andi
At 12:06 AM 11/18/2005, Jani Taskinen 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.phpWith 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 commitfiles
to our CVS repository to catch any errors early..this reminded
me to
fix that script to catch notices and such too. :)--Jani
Im aware of that, but my thinking was to add the things in for
that.... Maybe Davey will be willing, or I could give it a shot and see.
--
Eric Coleman
http://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176
Current release: 1.0.0 (stable) was released on 2005-03-15
That means it's not up to date enough to help with 5.0 -> 5.1
upgrades...----- Original Message -----
From: "Eric Coleman" eric@aplosmedia.com
To: "Andi Gutmans" andi@zend.com
Cc: "Jani Taskinen" sniper@iki.fi; truth@proposaltech.com;
internals@lists.php.net
Sent: Sunday, November 20, 2005 3:24 AM
Subject: Re: [PHP-DEV] Upgrading phpWhat about using http://pear.php.net/package/PHP_CompatInfo as a
basis? It seemed to do a pretty good job last time I ran it...
- Eric
--
Eric Colemanhttp://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6
comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.We had something similar to (a) and (b) when we moved people from
PHP/FI 2 to PHP 3 as there were some significant differences. That
said, it's not always simple because you might need to have to
reuse the scanner/parser and a simple PHP script might not be
enough.Hopefully, as we get closer to PHP 6 there will be people who have
time to invest in this.
Most important thing at this point, is to keep the upgrading docs
(which will be first released with 5.1) in sync with the changes,
so that when the time comes with PHP 6, it'll be easy to translate
the docs to such a script, without forgetting half the stuff that
was changed.Andi
At 12:06 AM 11/18/2005, Jani Taskinen 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.phpWith a simple shell script you can create a list of fileshaving
any errors/warnings/notices/strict.. :)At work we use a syntax checker script run whenever we commitfiles
to our CVS repository to catch any errors early..this reminded
me to
fix that script to catch notices and such too. :)--Jani
The PHP_CompatInfo package simply evaluates a script to find which is the
minimum version of PHP able to run it. Obviously it'll need updating for
PHP 5.1, and it may well be a helpful tool for users deciding whether an
upgrade is a good idea, but it's unlikely to be useful in the context under
discussion.
Andi was thinking of an auto-conversion tool for PHP 6 (something like
autoconf's autoupdate) - this isn't something that's likely to be achievable
in userspace code.
- Steph
----- Original Message -----
From: "Eric Coleman" eric@aplosmedia.com
To: "Steph Fox" steph@zend.com
Cc: "Andi Gutmans" andi@zend.com; "Jani Taskinen" sniper@iki.fi;
truth@proposaltech.com; internals@lists.php.net
Sent: Sunday, November 20, 2005 4:34 AM
Subject: Re: [PHP-DEV] Upgrading php
Im aware of that, but my thinking was to add the things in for
that.... Maybe Davey will be willing, or I could give it a shot and see.--
Eric Colemanhttp://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176Current release: 1.0.0 (stable) was released on 2005-03-15
That means it's not up to date enough to help with 5.0 -> 5.1
upgrades...----- Original Message -----
From: "Eric Coleman" eric@aplosmedia.com
To: "Andi Gutmans" andi@zend.com
Cc: "Jani Taskinen" sniper@iki.fi; truth@proposaltech.com;
internals@lists.php.net
Sent: Sunday, November 20, 2005 3:24 AM
Subject: Re: [PHP-DEV] Upgrading phpWhat about using http://pear.php.net/package/PHP_CompatInfo as a
basis? It seemed to do a pretty good job last time I ran it...
- Eric
--
Eric Colemanhttp://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6
comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.We had something similar to (a) and (b) when we moved people from
PHP/FI 2 to PHP 3 as there were some significant differences. That
said, it's not always simple because you might need to have to
reuse the scanner/parser and a simple PHP script might not be
enough.Hopefully, as we get closer to PHP 6 there will be people who have
time to invest in this.
Most important thing at this point, is to keep the upgrading docs
(which will be first released with 5.1) in sync with the changes,
so that when the time comes with PHP 6, it'll be easy to translate
the docs to such a script, without forgetting half the stuff that
was changed.Andi
At 12:06 AM 11/18/2005, Jani Taskinen 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.phpWith a simple shell script you can create a list of fileshaving
any errors/warnings/notices/strict.. :)At work we use a syntax checker script run whenever we commitfiles
to our CVS repository to catch any errors early..this reminded
me to
fix that script to catch notices and such too. :)--Jani
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
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
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:
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
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
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 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
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