Re: [PHP] Quick Poll: PHP 4 / 5
Rasmus Lerdorf schrieb: [...] What do we do with code like this? If you follow it through it is essentially doing: 3 = banana; This is obviously totally wrong and has to be noted as wrong, hence E_NOTICE. Since it can be dealt with without rendering the script unexecutable raising a fatal error in PHP5 is wrong = switch that to E_NOTICE, too. But the problem for a lot of people using PHP applications simply is that they had perfectly running code and they weren't getting any notices at all. Now they still have working code but this one error in code they haven't written is throwing notices at them like hell. The quick answer is deactivate error reporting for production systems, but this is not a real solution for the PHP 4.x platform. People _using_ foreign code expect to get consistent behaviour from their applications. So the report level for this should be configurable for the 4.x branch with silence as default. AllOLLi The good news is: The whiskey works. [Lost in Translation] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Robert Cummings wrote:
I don't agree with your position that the above code is incorrect
I think notices are fine for situations where you've probably screwed
up. I'd rather PHP let me know than do nothing.
I see this situation as being very similar to the following:
?php
function foo($bar)
{
/* ... */
}
foo(3);
?
This happens to throw a fatal error, which seems fine (mainly because it
always has, as far as I know, so no one can have working code that does
this sort of thing).
I'm curious to know whether you would also disagree that this code is
incorrect. I don't see a big fundamental difference, but I might be
misunderstanding something.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Quick Poll: PHP 4 / 5
Chris,
You probably are aware that this comes from a C/C++ standard the '' before
the variable means that you are passing by reference and not by value. If
you are passing by reference, you are passing the address of a variable
instead of the value of that variable.
By passing the value of 3 the script crashes because it thinks that you are
passing a pointer to address 3 in memory. This means the computer thinks
that the value being passed to the function is located in memory address '3'
which is invalid because that memory address is reserved for the OS (at
least on most machines the lowest memory addresses are reserved for the OS.)
In order to make your code work you would have to pass a variable so that
the computer can get the address of that variable and use/compute the data
located there.
Sounds like the original problem is some kind of type mismatch of this sort.
Carl
-Original Message-
From: Chris Shiflett [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 18, 2005 4:10 PM
To: Robert Cummings
Cc: Rasmus Lerdorf; Stephen Leaf; PHP-General
Subject: Re: [PHP] Quick Poll: PHP 4 / 5
Robert Cummings wrote:
I don't agree with your position that the above code is incorrect
I think notices are fine for situations where you've probably screwed
up. I'd rather PHP let me know than do nothing.
I see this situation as being very similar to the following:
?php
function foo($bar)
{
/* ... */
}
foo(3);
?
This happens to throw a fatal error, which seems fine (mainly because it
always has, as far as I know, so no one can have working code that does
this sort of thing).
I'm curious to know whether you would also disagree that this code is
incorrect. I don't see a big fundamental difference, but I might be
misunderstanding something.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
On Sun, 2005-09-18 at 16:10, Chris Shiflett wrote:
Robert Cummings wrote:
I don't agree with your position that the above code is incorrect
I think notices are fine for situations where you've probably screwed
up. I'd rather PHP let me know than do nothing.
I see this situation as being very similar to the following:
?php
function foo($bar)
{
/* ... */
}
foo(3);
?
This happens to throw a fatal error, which seems fine (mainly because it
always has, as far as I know, so no one can have working code that does
this sort of thing).
I'm curious to know whether you would also disagree that this code is
incorrect. I don't see a big fundamental difference, but I might be
misunderstanding something.
I have no argument about what you have shown above, but it becomes a
tricker question when you have the following which is similar but not
exactly what you have shown:
function foo( $bar )
{
/* ... */
}
function fee( $beer )
{
return ($beer + 1);
}
foo( fee( 3 ) )
So the point being made here is that fee returns a variable container
(temporary or otherwise) and not a constant, however, with the new
system that is as incorrect as the foo( 3 ) you have expressed. Either
way, Rasmus has admitted that the new current system is a bit
aggressive, but points out (as do you) that it is better to generate a
notice just in case. And I already responded to that response by Rasmus'
with grudging agreement :)
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Carl Furst wrote: Chris, You probably are aware that this comes from a C/C++ standard the '' before the variable means that you are passing by reference and not by value. You are probably not aware that I'm not asking a question. :-) Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
- Original Message - From: Jasper Bryant-Greene [EMAIL PROTECTED] To: php-general@lists.php.net Sent: Friday, September 16, 2005 11:14 PM Subject: Re: [PHP] Quick Poll: PHP 4 / 5 leaf wrote: Actually I choose array_pop for 2 reasons. I like short code. I don't want to read thousands of lines just to get an idea. I tend to think in very compact code. if you find that ugly and unreadable. that's your preference. I find extended coding very ugly, mostly because I'm a slow reader, and that is my preference And what about someone else that has to read/maintain your code in the future? What about when you come to read a clever but compact line of code that does 5 or 6 things on a single line, a few years down the track, and spend valuable time just trying to figure out what it actually does? I think in compact code. so reading it back is not a problem. As for future programmers who want to look at my code? That's never happened so far. However I do keep good documentation. so reading and understanding my code shouldn't be a problem. I got use to working with pop and shift while I was doing perl work. so to me pop'ing an array makes perfect sense. Sure, when there actually *is* an array to pop. In the following situation there is no array to actually pop (remove and return) the last element from, since you're using the return value of explode() while array_pop() expects a reference to a variable: $element = array_pop( explode( ',', $some_string ) ); No array to pop? .. explode returns an array. doesn't matter if its temporary or has a variable assigned to it. its still an array. -- Jasper Bryant-Greene Freelance web developer http://jasper.bryant-greene.name/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Stephen Leaf wrote:
$this-urlArr[0] = array_pop($arr = explode(,$this-urlArr[0]));
I still have to scratch my head as to why I *need* that $arr =
prior to 5.0.5 this was not needed.
$this-urlArr[0] = array_pop(explode(,$this-urlArr[0]));
This is a much misunderstood issue. And we are still contemplating the
best way to handle this. Let's take a step back to a really simple example:
function foo() {
return 3;
}
function bar($arg) {
$arg = banana;
}
bar(foo());
What do we do with code like this? If you follow it through it is
essentially doing:
3 = banana;
which makes very little sense and is probably something the developer
would want to know about. PHP 4.3.x happily let you do this, and in
some circumstances this could even corrupt memory. PHP 4.4 and higher
have fixed this memory corruption problem, and at the same time since we
are now able to detect this we can throw an error to let you know that
your code is probably not doing what you intended.
Now, in your example you are doing:
$a = array_pop(explode(,ab));
to get the last element from the explode. The issue with array_pop()
and other similar functions is that they do 2 things. They modify the
array (by removing the last element) and they return something (the
removed element in this case). When you pass in the result of explode()
you are passing in something that doesn't have any permanent storage
associated with it. Internally in PHP this is known as a temp var. You
can't make a reference to a temp var. In our simpler example it is like
trying to do 3 which doesn't make any sense. So in this case
array_pop() has no place to store the modification. Your code happens
to not care about that and only cares about the returned value.
The real question here is whether we should silently ignore cases where
such an argument modification is thrown away. In the case of
array_pop() it may make sense. But how about this:
sort(explode(,ab));
sort() has just one purpose. That is to sort the passed array in place.
The above line of code is a really slow line of code that does
absolutely nothing because we are passing in something that goes out of
scope as soon as the call is done. This line of code in a PHP program
is an obvious bug. Now, if we change this to:
sort($a=explode(,ab));
then it suddenly makes sense. This is equivalent to writing:
$a = explode(,ab));
sort($a);
and the result is that we have a sorted array in $a after this.
So the idea here is that PHP should be able to detect these sorts of
obvious errors. In the array_pop() case it is not as black and white as
the sort() case because of the dual-purpose nature of array_pop(). You
could make a case for silently ignoring the array modification in
array_pop().
My personal feeling on this is that we should throw an E_NOTICE on these
and let the code continue on. Often there is a more efficient way to do
some of these things simply because you are calling something that does
more than you need and ignoring some of what the function does and other
times, like with the sort() example, this is actually a real bug in your
code.
If it wasn't for the memory corruption associated with this, we wouldn't
have touched it in PHP 4 at all. But since it caused weird and
wonderful crashes in complex PHP 4 code we didn't really have the option
to ignore it. So what we do now is to demote impossible references to
non-references and throw an E_NOTICE. In PHP 5 this ended up being a
fatal error which is something we have been discussing over the past
week. In its current state having this as a fatal error is incorrect
and something we will fix. We need to either make it an E_NOTICE or
there has been talk about coming up with a smarter way of handling these
impossible reference cases, but it is pretty tricky.
We don't always get things right on the first try. Expect to see some
tweaks to the current implementation to make it more compatible with
existing code over the next couple of weeks.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Can't expect everything to be done right on the first try. But it sure was a
big annoyance. Great to hear that work is being done to improve on this.
I personally would rather it just be silently ignored as to me an error line
at the top is the same as it not working at all.
Would love to find a tool that could go over code and output errors like this
tho. Provide a better solution or whatever along with all the dumb mistakes
that PHP is ignoring for you.
With my experiences I have never used pointers or references in PHP. I'm sure
they are powerful and all. but I just don't want to mess with them or have
worry about them. That's just 1 thing in programming I don't have much
experience with. I give a function a variable and I think I'm passing the
value. if the function takes the reference and modifies that.. oh well.. I
got my result back that's all I care about :)
as for the sort thought. If the programmer does that and can't figure out
what's going on.. they obviously didn't read the manual or just don't know
basic programming ;)
bool sort ( array array [, int sort_flags] )
Returns bool.. that's not an array ;) If it takes an array but doesn't return
an array.. it must operate on the passed in array if it didn't what a useless
function. Lets sort the array and say yah we sorted it but you can't have
it :)
So yes a bug. But for those that want to be able to grab only what we need. in
my case array_pop's returned element. I don't wanna be hassled with the are
you sure you wanted to ignore part of what we did?
It's almost like every program asking are you sure you wanted to close me?
everytime I get asked that I always think... I did just click the X.. so
Yah...
Just my 2 cents. I'm sure you guys will come up with something.. either way
PHP is the only language I'll use for a website. Thank you very much for the
detailed reason behind this.
On Friday 16 September 2005 09:28 am, Rasmus Lerdorf wrote:
Stephen Leaf wrote:
$this-urlArr[0] = array_pop($arr = explode(,$this-urlArr[0]));
I still have to scratch my head as to why I *need* that $arr =
prior to 5.0.5 this was not needed.
$this-urlArr[0] = array_pop(explode(,$this-urlArr[0]));
This is a much misunderstood issue. And we are still contemplating the
best way to handle this. Let's take a step back to a really simple
example:
function foo() {
return 3;
}
function bar($arg) {
$arg = banana;
}
bar(foo());
What do we do with code like this? If you follow it through it is
essentially doing:
3 = banana;
which makes very little sense and is probably something the developer
would want to know about. PHP 4.3.x happily let you do this, and in
some circumstances this could even corrupt memory. PHP 4.4 and higher
have fixed this memory corruption problem, and at the same time since we
are now able to detect this we can throw an error to let you know that
your code is probably not doing what you intended.
Now, in your example you are doing:
$a = array_pop(explode(,ab));
to get the last element from the explode. The issue with array_pop()
and other similar functions is that they do 2 things. They modify the
array (by removing the last element) and they return something (the
removed element in this case). When you pass in the result of explode()
you are passing in something that doesn't have any permanent storage
associated with it. Internally in PHP this is known as a temp var. You
can't make a reference to a temp var. In our simpler example it is like
trying to do 3 which doesn't make any sense. So in this case
array_pop() has no place to store the modification. Your code happens
to not care about that and only cares about the returned value.
The real question here is whether we should silently ignore cases where
such an argument modification is thrown away. In the case of
array_pop() it may make sense. But how about this:
sort(explode(,ab));
sort() has just one purpose. That is to sort the passed array in place.
The above line of code is a really slow line of code that does
absolutely nothing because we are passing in something that goes out of
scope as soon as the call is done. This line of code in a PHP program
is an obvious bug. Now, if we change this to:
sort($a=explode(,ab));
then it suddenly makes sense. This is equivalent to writing:
$a = explode(,ab));
sort($a);
and the result is that we have a sorted array in $a after this.
So the idea here is that PHP should be able to detect these sorts of
obvious errors. In the array_pop() case it is not as black and white as
the sort() case because of the dual-purpose nature of array_pop(). You
could make a case for silently ignoring the array modification in
array_pop().
My personal feeling on this is that we should throw an E_NOTICE on these
and let the code continue on. Often there is a more efficient way to do
some of these things simply because
Re: [PHP] Quick Poll: PHP 4 / 5
On Fri, 2005-09-16 at 10:28, Rasmus Lerdorf wrote:
Stephen Leaf wrote:
$this-urlArr[0] = array_pop($arr = explode(,$this-urlArr[0]));
I still have to scratch my head as to why I *need* that $arr =
prior to 5.0.5 this was not needed.
$this-urlArr[0] = array_pop(explode(,$this-urlArr[0]));
This is a much misunderstood issue. And we are still contemplating the
best way to handle this. Let's take a step back to a really simple example:
function foo() {
return 3;
}
function bar($arg) {
$arg = banana;
}
bar(foo());
What do we do with code like this? If you follow it through it is
essentially doing:
3 = banana;
which makes very little sense and is probably something the developer
would want to know about.
I think this is part of the problem. While I understand how you got
3 = banana
I don't agree with your position that the above code is incorrect,
rather I think there is a philosophical difference between some
developers as to what should be expected. Most programmers (I would
argue :), including myself say, Foo returns 3, the return value is
stored in a temporary container, the temporary container is then fed
into bar() which just happens to want a reference, so fine, it gets a
reference to a temporary container, then it sets the value to banana.
So finally we get back out to the bar(foo()) calling scope and we
receive the temporary container. In which case the way people are using
these functions and references are perfectly valid and passing temporary
return containers to reference expecting functions is not necessarily a
bug, but a philosophical question of understanding what the hell you're
doing :) As you are seeing now, we now have a horrible situation where
the developer now has to care about whether they are passing a value to
a function expecting a reference or not, and if that function expects a
reference they now have to manually create a temporary container
themselves :/ Anyways, I've already accepted whatever comes out of all
this, but personally I don't think the code you showed above is wrong at
all :)
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Robert Cummings wrote:
On Fri, 2005-09-16 at 10:28, Rasmus Lerdorf wrote:
Stephen Leaf wrote:
$this-urlArr[0] = array_pop($arr = explode(,$this-urlArr[0]));
I still have to scratch my head as to why I *need* that $arr =
prior to 5.0.5 this was not needed.
$this-urlArr[0] = array_pop(explode(,$this-urlArr[0]));
This is a much misunderstood issue. And we are still contemplating the
best way to handle this. Let's take a step back to a really simple example:
function foo() {
return 3;
}
function bar($arg) {
$arg = banana;
}
bar(foo());
What do we do with code like this? If you follow it through it is
essentially doing:
3 = banana;
which makes very little sense and is probably something the developer
would want to know about.
I think this is part of the problem. While I understand how you got
3 = banana
I don't agree with your position that the above code is incorrect,
rather I think there is a philosophical difference between some
developers as to what should be expected. Most programmers (I would
argue :), including myself say, Foo returns 3, the return value is
stored in a temporary container, the temporary container is then fed
into bar() which just happens to want a reference, so fine, it gets a
reference to a temporary container, then it sets the value to banana.
So finally we get back out to the bar(foo()) calling scope and we
receive the temporary container. In which case the way people are using
these functions and references are perfectly valid and passing temporary
return containers to reference expecting functions is not necessarily a
bug, but a philosophical question of understanding what the hell you're
doing :)
Well, this is the sort of thing the language should help you with.
Whether or not the code is incorrect or not is not the relevant question
I think. The question is whether the language should try to detect when
you are doing something that is not going to do what you expect. If
someone really writes code like the above, I see it as a plus if they
could get an optional warning about it. That's exactly what an E_NOTICE
on this is for.
As you are seeing now, we now have a horrible situation where
the developer now has to care about whether they are passing a value to
a function expecting a reference or not, and if that function expects a
reference they now have to manually create a temporary container
themselves :/ Anyways, I've already accepted whatever comes out of all
this, but personally I don't think the code you showed above is wrong at
all :)
Well, you can turn off notices, or rather not turn them on since they
are off by default, and you won't have to care. Like I said, the
current fatal error in 5.0.5 on this is incorrect and we will fix that,
but I still believe it is a good idea to provide users with a way to get
warnings on cases where references are dropped since it could very well
hide a bug in their code.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
On Fri, 2005-09-16 at 14:10, Rasmus Lerdorf wrote: Well, this is the sort of thing the language should help you with. Whether or not the code is incorrect or not is not the relevant question I think. The question is whether the language should try to detect when you are doing something that is not going to do what you expect. If someone really writes code like the above, I see it as a plus if they could get an optional warning about it. That's exactly what an E_NOTICE on this is for. As you are seeing now, we now have a horrible situation where the developer now has to care about whether they are passing a value to a function expecting a reference or not, and if that function expects a reference they now have to manually create a temporary container themselves :/ Anyways, I've already accepted whatever comes out of all this, but personally I don't think the code you showed above is wrong at all :) Well, you can turn off notices, or rather not turn them on since they are off by default, and you won't have to care. Like I said, the current fatal error in 5.0.5 on this is incorrect and we will fix that, but I still believe it is a good idea to provide users with a way to get warnings on cases where references are dropped since it could very well hide a bug in their code. Yeah, I concede the point *grumbling under my breath* that people should probably get a notice, although for me that's just as bad as a warning since I don't like getting notices while developing. It gives me (and probably anybody who ever views such code in a development environment) the feeling that it's incorrect. I guess that's one of the problems about being anal about code and I don't think I'm alone with this feeling ;) I've taken over code in that past that's been known to generate 1000's of E_NOTICES and E_WARNINGS and just as expected, all kinds of bugs were present *heheh*. Right up there with code that thinks it's ok to send 10k sql queries to facilitate some purist idea of OOP data retrieval :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Stephen Leaf wrote: So yes a bug. But for those that want to be able to grab only what we need. in my case array_pop's returned element. I don't wanna be hassled with the are you sure you wanted to ignore part of what we did? It's almost like every program asking are you sure you wanted to close me? everytime I get asked that I always think... I did just click the X.. so Yah... But why use array_pop() to get the last element, when you know it's intended to shorten its passed array as well? I mean, sure, it might take a few more lines of code to do it properly, but it has the advantage that whoever has to look at the code next might actually understand what's going on in your head. $array = explode( ',', $some_string ); $last_element_pos = count( $array ) - 1; $last_element = $array[$last_element_pos]; [ sure, you could put the count( $array ) - 1 as the array subscript but I was just extending it out for illustration... it's probably easier to understand later on anyway. ] -- Jasper Bryant-Greene Freelance web developer http://jasper.bryant-greene.name/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hello, on 09/15/2005 09:32 AM Oliver Grätz said the following: First of all, in many cases code reuse still is a myth. I hate to say it but it's true. Then, a large potion of the PHP community hasn't even heard of PEAR. Then, people definitely start projects from scratch. If You don't know if you have any numbers to back the large portion of the PHP community claim. The proof is the sheer number of this is *THE* PHP application framework to use sites on the internet. Some people don't like reusing code, some evaluate those projects and decide against them. For my part, before reinventing the wheel I always spend some time serching through PEAR and the web but very often the available solutions don't fit my needs. I simply suppose other developers tend to act the same way. That is not proof of your claim. It is just your opinion without figures to back the clain Anyway, as the developer of phpclasses.org, the largest PHP class repository, I can inform you that the site has accumulated near 270,000 subscriber since 1999, of which at least half of them are considered active as you may verify here: http://www.phpclasses.org/browse/statistics/statistics.html The site has 2,200 approved packages but only 71 are PHP 5 specific. That is a lot of people reusing a lot of public class libraries! Ah, that thing. The site that always gives me problems when I try to log I have no idea what problems are talking. All sessions expire after 30 days. If you need to access something that requires authentication, you need to login after 30 days of abscense. If you do not recall your password, you can ask a reminder or to reset the password. Other than that, I don't know problems are you talking about? in after absence. I had switched to reregistering for every access before Berlios came along (thanks for threatening to sue them) and now I use the Monster TGZs. I am afraid you are also misunderstanding the matters. That fellow was abusing from the site in several ways. One is that he was ripping all the title and descriptions of the packages that I enter when I approve a class. That is a copyright violation. Another thing is that he was employing robots to leech the site. Not only it was causing excessive load to the server but he was also causing excessive bandwidth usage. Anyway, I do not care if whoever replicates the package files available in the site. If you want to waste bandwidth on that, that is your problem. I just can't accept serving files to people that act with malice against a site that serves tens of thousands of PHP users, causing me financial expenses that the site advertising revenue can't cover. After all what do you want? Shut down the site so no PHP user can benefit from it? Anyway, the problem of excessive load and bandwidth, was not being cause by just that fellow. Therefore, in case you do not know, several measures were taken to discourage the use of robots. All the users receiving the site newsletter were told about this. If you have not been in the site lately, once you get there you will realize why leeches will have an hard time to work now. This means that it will be hard to keep up with replication repositories. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
- Original Message - From: Jasper Bryant-Greene [EMAIL PROTECTED] To: php-general@lists.php.net Sent: Friday, September 16, 2005 4:45 PM Subject: Re: [PHP] Quick Poll: PHP 4 / 5 Stephen Leaf wrote: So yes a bug. But for those that want to be able to grab only what we need. in my case array_pop's returned element. I don't wanna be hassled with the are you sure you wanted to ignore part of what we did? It's almost like every program asking are you sure you wanted to close me? everytime I get asked that I always think... I did just click the X.. so Yah... But why use array_pop() to get the last element, when you know it's intended to shorten its passed array as well? I mean, sure, it might take a few more lines of code to do it properly, but it has the advantage that whoever has to look at the code next might actually understand what's going on in your head. $array = explode( ',', $some_string ); $last_element_pos = count( $array ) - 1; $last_element = $array[$last_element_pos]; [ sure, you could put the count( $array ) - 1 as the array subscript but I was just extending it out for illustration... it's probably easier to understand later on anyway. ] Actually I choose array_pop for 2 reasons. I like short code. I don't want to read thousands of lines just to get an idea. I tend to think in very compact code. if you find that ugly and unreadable. that's your preference. I find extended coding very ugly, mostly because I'm a slow reader, and that is my preference I got use to working with pop and shift while I was doing perl work. so to me pop'ing an array makes perfect sense. -- Jasper Bryant-Greene Freelance web developer http://jasper.bryant-greene.name/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
leaf wrote: Actually I choose array_pop for 2 reasons. I like short code. I don't want to read thousands of lines just to get an idea. I tend to think in very compact code. if you find that ugly and unreadable. that's your preference. I find extended coding very ugly, mostly because I'm a slow reader, and that is my preference And what about someone else that has to read/maintain your code in the future? What about when you come to read a clever but compact line of code that does 5 or 6 things on a single line, a few years down the track, and spend valuable time just trying to figure out what it actually does? I got use to working with pop and shift while I was doing perl work. so to me pop'ing an array makes perfect sense. Sure, when there actually *is* an array to pop. In the following situation there is no array to actually pop (remove and return) the last element from, since you're using the return value of explode() while array_pop() expects a reference to a variable: $element = array_pop( explode( ',', $some_string ) ); -- Jasper Bryant-Greene Freelance web developer http://jasper.bryant-greene.name/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
On Sat, 2005-09-17 at 00:14, Jasper Bryant-Greene wrote: leaf wrote: Actually I choose array_pop for 2 reasons. I like short code. I don't want to read thousands of lines just to get an idea. I tend to think in very compact code. if you find that ugly and unreadable. that's your preference. I find extended coding very ugly, mostly because I'm a slow reader, and that is my preference And what about someone else that has to read/maintain your code in the future? What about when you come to read a clever but compact line of code that does 5 or 6 things on a single line, a few years down the track, and spend valuable time just trying to figure out what it actually does? I got use to working with pop and shift while I was doing perl work. so to me pop'ing an array makes perfect sense. Sure, when there actually *is* an array to pop. In the following situation there is no array to actually pop (remove and return) the last element from, since you're using the return value of explode() while array_pop() expects a reference to a variable: $element = array_pop( explode( ',', $some_string ) ); Ahhh but there is an array to pop, returned arrays are still containers and generally follow the semantics of declared containers (obscure segfault bugs notwithstanding). Personally I find: $element = array_pop( explode( ',', $some_string ) ); More readable than: list( $element ) = explode( ',', $some_string ); But that's because I find assigning to something that looks like a function disconcerting :) Maybe what we really need is: // // First parameter should be a reference and will be altered to // reflect the popping of the substring separated by the separator. // The second parameter is the separator to use, comma is defaulted // but we set it explicitly for readability ;) // $element = str_pop( $some_string, ',' ); Of course, as soojn as you do that, you know someone will do the following: $element = str_pop( $some_part1.$some_part2, ',' ) Or even worse (teehee): $element = str_pop( implode( ',', $some_array ) ) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Stephen Leaf wrote: On Tuesday 13 September 2005 05:52 pm, Ryan A wrote: [x] I never work with PHP 4 anymore, all my work is with PHP 5 so far I've not found any hosts that do PHP5, however I do all my own hosting anyway. I've switched to use PHP5 because I was interested in doing XSL, and the concept of doing objects intrigues me. XSL support in 5 is far superior. It's a walk in the park now, where as before it was quite confusing. I'm currently doing a project where the client doesn't know what she wants... because of this I'm constantly having to redo sections to add what she wants. So taking this approach for this client has saved me from 10 times more work. I personally can't wait for PDO. I do lots of projects that all use SQL thats because you don't use firebird DB ;-) (SQLite, PostgreSQL and MySQL) Right now I have to recode everything to use the right DB. with my newest project I'm using SQLite with a custom Object to handle the DB Object. It's actually design with PDO in mind. After they get PDO in and working well It'll save me hours of work. From that Website about the 6 dumbest ideas. I guess you could say I'm an early adopter I like ideas that'll save me time in the long run, even if I'm the one that has to do tons of testing to make it usable. The long run is what matters to me. If I can spend time learning, testing.. and then later be able to do something in 5 mins that'd take 15 the old way.. I'm up for it. Has to be someone to do the testing to bring projects forward isn't there ? ;) From the opposite side of the spectrum I have had my share of upgrade issues. One was from 5.0.4 to 5.0.5 $this-urlArr[0] = array_pop($arr = explode(,$this-urlArr[0])); I still have to scratch my head as to why I *need* that $arr = prior to 5.0.5 this was not needed. prior to 5.0.5 this was allowed but technically its the cause of memory corruption and has now been madce into a fatal error - the reason is that array_pop() takes its arg as a reference (to a variable) - if you pass it the return value of a function then its technically not referencing something that exists because the value (the array that explode returns) only exists in the scope of the explode function call and that dies when explode returns placing the '$arr =' means you are assigning the return value of explode() to $arr and passing a reference to the same variable. $this-urlArr[0] = array_pop(explode(,$this-urlArr[0])); Perhaps someone here could tell me what was change to make this happen.. and how does that change make the engine better? It seemed to work perfectly fine before. 'seemed' being the operative word. allowing code without the '$arr =' (from your example) is/was the source of many strange/subtle difficult (impossible) to debug segmentation faults (memory corruption) which quite often sprung up in large/complex codebases. I've also had to upgrade a few classes written for PHP4 specifically ones that like to use: var $variable; Overall, If you can upgrade to 5 .. do so. the advantages in my cases have been so nice. If you can't upgrade, Don't. Use what works. I personally would urge you to upgrade to 5 if you wanna get in deep with objects. I'm sure that 3 and 4 can do them just fine. but whats the use of learning how to do OOP in something that has been updated? Or worded differently, Why learn old ways when you can benefit from newer ideas/implementations ? It'd be like putting logs under a platform and repositioning the log that came out the back in the front again as a way to move something instead of wagon just because it's always worked before. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Manuel Lemos schrieb: A reference where _I_ have to search is something like a non-answer... If you try searching the bug database for PHP 4 versus PHP 5 opened bug reports you will get your answer. Same sentence still applies. But OK: PHP4 has 518 open bugs, PHP5 only 203. What does this say about the stability of PHP4? http://bugs.php.net/bugstats.php?phpver=4 http://bugs.php.net/bugstats.php?phpver=5 Also, PHP4 (first beta 19-Jul-1999) has a history of over 25300 bugs in its 6 year long history whereas PHP5 (first beta 29-Jun-2003) has had less than 4300 bugs filed in 2 years. Project this to 6 years and you are at 13000 filed bugs, roughly half as many as for PHP4. The site also states that PHP5 bugs are handled more quickly: PHP5: 47/3 vs PHP4: 71/5 (days average/median lifetime). So, you send me a link supporting my arguments. Thank you. In case it was not clear for you, what I am saying is not the matter is PHP 4.x vs. PHP 5.x, but rather upgrading vs. not upgrading. [...] I've got PHP5 and 4 running on the same machine. I just do not get why you still run PHP 4 when you are so confident that PHP 5 is the right version to use. Didn't you give yourself the answer? I'm not using PHP5 (read: upgrading) for stuff that doesn't want it (meaning its debian package requires PHP4). For my own projects I use PHP5 and if I decide to use some packages meant to be used with PHP4 I have yet to encounter real problems that are PHP5-problems. First of all, in many cases code reuse still is a myth. I hate to say it but it's true. Then, a large potion of the PHP community hasn't even heard of PEAR. Then, people definitely start projects from scratch. If You don't know if you have any numbers to back the large portion of the PHP community claim. The proof is the sheer number of this is *THE* PHP application framework to use sites on the internet. Some people don't like reusing code, some evaluate those projects and decide against them. For my part, before reinventing the wheel I always spend some time serching through PEAR and the web but very often the available solutions don't fit my needs. I simply suppose other developers tend to act the same way. Anyway, as the developer of phpclasses.org, the largest PHP class repository, I can inform you that the site has accumulated near 270,000 subscriber since 1999, of which at least half of them are considered active as you may verify here: http://www.phpclasses.org/browse/statistics/statistics.html The site has 2,200 approved packages but only 71 are PHP 5 specific. That is a lot of people reusing a lot of public class libraries! Ah, that thing. The site that always gives me problems when I try to log in after absence. I had switched to reregistering for every access before Berlios came along (thanks for threatening to sue them) and now I use the Monster TGZs. AllOLLi \let\thepage\relax -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
On Thu, 2005-09-15 at 08:32, Oliver Grätz wrote: Manuel Lemos schrieb: A reference where _I_ have to search is something like a non-answer... If you try searching the bug database for PHP 4 versus PHP 5 opened bug reports you will get your answer. Same sentence still applies. But OK: PHP4 has 518 open bugs, PHP5 only 203. What does this say about the stability of PHP4? http://bugs.php.net/bugstats.php?phpver=4 http://bugs.php.net/bugstats.php?phpver=5 Bug count is not necessarily indicative of stability issues. If there are 100 bugs for a seldom used function and a single bug for a ubiquitous function then the latter decreases stability more than the former. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
2005/9/13, Ryan A [EMAIL PROTECTED]: Hi, I work for a company that makes websites and does custom programming for private indviduals and companies, I also freelance (like many on this list) I'm a bit curious, so far I have had no need to upgrade my skills or use the slightly different format / functions of PHP 5.x.infact I have not seen all that many hosts actually having support for it, so I thought of this little poll :-) Simply cross all the boxes that applies and reply to the list (along with your name on top) eg: [x] blah blah [] I am still working on PHP 4 [] I never work with PHP 4 anymore, all my work is with PHP 5 [] Oops, call me old fashioned but i am still with 3! [] I have no problems finding a host with PHP 5 support [] I can handle PHP 5, but I only work with PHP 4 [] Nah, will wait till PHP 6 is out, theres not much diff between 4 and 5 [] PHP 5 sounds / looks too hard to learn [x] I use a layer above PHP which is independant of whether it's PHP4 or PHP 5, which is running Migration from 4.x to 5.0.3 was as simple as changing a DNS record :-) http://templeet.org/ -- Pooly Webzine Rock : http://www.w-fenec.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
On Thu, 2005-09-15 at 16:25, Pooly wrote: 2005/9/13, Ryan A [EMAIL PROTECTED]: Hi, I work for a company that makes websites and does custom programming for private indviduals and companies, I also freelance (like many on this list) I'm a bit curious, so far I have had no need to upgrade my skills or use the slightly different format / functions of PHP 5.x.infact I have not seen all that many hosts actually having support for it, so I thought of this little poll :-) Simply cross all the boxes that applies and reply to the list (along with your name on top) eg: [x] blah blah [] I am still working on PHP 4 [] I never work with PHP 4 anymore, all my work is with PHP 5 [] Oops, call me old fashioned but i am still with 3! [] I have no problems finding a host with PHP 5 support [] I can handle PHP 5, but I only work with PHP 4 [] Nah, will wait till PHP 6 is out, theres not much diff between 4 and 5 [] PHP 5 sounds / looks too hard to learn [x] I use a layer above PHP which is independant of whether it's PHP4 or PHP 5, which is running Migration from 4.x to 5.0.3 was as simple as changing a DNS record :-) http://templeet.org/ A layer above suggests you never touch PHP syntax. I doubt that's a true claim. Otherwise you're just as prone to the difference between PHP4 and PHP5 as soon as you start writing PHP syntax. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Pooly schrieb: [x] I use a layer above PHP which is independant of whether it's PHP4 or PHP 5, which is running Migration from 4.x to 5.0.3 was as simple as changing a DNS record :-) http://templeet.org/ A layer above PHP would mean this thing generates code specific to the underlying PHP version or features PHP-version-based code switching. I doubt that. It surely is a PHP application in itself and therefore subject to problems depending on the PHP version used underneath. AllOLLi Hostage: You son of a bitch. Soong: Actually mother was a chemist. [Enterprise 405] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
hi Ryan, here are my crosses :-) It would be nice if you could compile a small summary at some stage based on the replies - any chance of that? Ryan A wrote: ... [x] I am still working on PHP 4 [] I never work with PHP 4 anymore, all my work is with PHP 5 [] Oops, call me old fashioned but i am still with 3! [x] I have no problems finding a host with PHP 5 support [] I can handle PHP 5, but I only work with PHP 4 [] Nah, will wait till PHP 6 is out, theres not much diff between 4 and 5 [] PHP 5 sounds / looks too hard to learn [x] Other All my new stuff is in php5 unless I'm forced otherwise. I maintain quite a bit of php4 code which I can't upgrade to php5 without a major rewrite (which will happen when hell freezes over) I mostly run on my own servers, some of my clients have dedicated hardware which I can install what ever is needed onto. the hosting I do use is very flexible in getting me the tools I want/need - I ask them 'any chance of php5' 15 minutes later I have access to a fully functional production box with php5 (etc). my hosting guys are a small technical outfit and rather nice to me :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Manuel Lemos schrieb: In theory those are the only changes. In practice, besides the officially admitted changes, there are also the bugs that were not yet discovered or fixed. Examples? Links? More information on this? The fact is that on php.internals there are discussions to reduce the number of maintained development threads. In the not-so-far future they will reduce the manpower put into backporting bugfixes to the PHP4.x development branch since 5.x is the HEAD revision and everything is first fixed there. I think all old stuff is just as mature in PHP5 as you know it from PHP4 and if some errors are found they are likely to be fixed more quickly for the 5.x release. The new stuff (that wasn't there before 5.0) almost certainly has more bugs since it's younger but that's no argument since this isn't relevant for old projects. I think the change from 4 to 5 ist that slow because there are so many programmers with VisualBasic (or worse) background that don't see the benefits of OOP. Iterators and delegation via interceptors are cool !?!? You can do OOP since PHP 3. PHP 5 OOP improvements are nice but they will not make anybody richer. The OOP features of PHP3 were nothing more than some kind of crippled namespaces for functions. PHP4 improved on that but PHP5 was the version to bring real OOP features to the language. It's the first versions to feature destructors and the possibility to overload parts of the Zend Engine for iterators or array access. You couldn't do $adr=new DB_Adress(12); // loads the adress with ID 12 from DB $adr['street']='Market Street'; // change the property //... // end of script, save changes to DB ? before PHP5. [...] As a matter of fact I just read this interesting article named The Six Dumbest Ideas in Computer Security that demonstrates what I always knew that upgrading to the latest versions is often a bad idea. Read the point #6) Action is Better Than Inaction . http://www.ranum.com/security/computer_security/editorials/dumb/ Nice article. Read it myself a few days ago (wasn't the link featured on Slashdot? *g*). Delaying upgrades might be true for running systems. But there's nothing keeping you from running both PHP4 and PHP5 on the same machine for different projects. And if you start a project from scratch PHP5 is the way to go. AllOLLi I just found the last bug. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Manuel Lemos schrieb: In theory those are the only changes. In practice, besides the officially admitted changes, there are also the bugs that were not yet discovered or fixed. Examples? Links? More information on this? The fact is that on php.internals there are discussions to reduce the number of maintained development threads. In the not-so-far future they will reduce the manpower put into backporting bugfixes to the PHP4.x development branch since 5.x is the HEAD revision and everything is first fixed there. I think all old stuff is just as mature in PHP5 as you know it from PHP4 and if some errors are found they are likely to be fixed more quickly for the 5.x release. The new stuff (that wasn't there before 5.0) almost certainly has more bugs since it's younger but that's no argument since this isn't relevant for old projects. I think the change from 4 to 5 ist that slow because there are so many programmers with VisualBasic (or worse) background that don't see the benefits of OOP. Iterators and delegation via interceptors are cool !?!? You can do OOP since PHP 3. PHP 5 OOP improvements are nice but they will not make anybody richer. The OOP features of PHP3 were nothing more than some kind of crippled namespaces for functions. PHP4 improved on that but PHP5 was the version to bring real OOP features to the language. It's the first versions to feature destructors and the possibility to overload parts of the Zend Engine for iterators or array access. You couldn't do $adr=new DB_Adress(12); // loads the adress with ID 12 from DB $adr['street']='Market Street'; // change the property //... // end of script, save changes to DB ? before PHP5. [...] As a matter of fact I just read this interesting article named The Six Dumbest Ideas in Computer Security that demonstrates what I always knew that upgrading to the latest versions is often a bad idea. Read the point #6) Action is Better Than Inaction . http://www.ranum.com/security/computer_security/editorials/dumb/ Nice article. Read it myself a few days ago (wasn't the link featured on Slashdot? *g*). Delaying upgrades might be true for running systems. But there's nothing keeping you from running both PHP4 and PHP5 on the same machine for different projects. And if you start a project from scratch PHP5 is the way to go. AllOLLi I just found the last bug. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hello, on 09/14/2005 01:30 PM Oliver Grätz said the following: In theory those are the only changes. In practice, besides the officially admitted changes, there are also the bugs that were not yet discovered or fixed. Examples? Links? More information on this? The fact is that on http://bugs.php.net/ php.internals there are discussions to reduce the number of maintained development threads. In the not-so-far future they will reduce the manpower put into backporting bugfixes to the PHP4.x development branch since 5.x is the HEAD revision and everything is first fixed there. I In theory yes, in practice no. As a matter of fact PHP 4.4 was introduced after PHP 5.0, although the new version, new bugs is the same. think all old stuff is just as mature in PHP5 as you know it from PHP4 and if some errors are found they are likely to be fixed more quickly for the 5.x release. The new stuff (that wasn't there before 5.0) almost certainly has more bugs since it's younger but that's no argument since this isn't relevant for old projects. Right, that is why most people with old projects will not upgrade to PHP 5. I think the change from 4 to 5 ist that slow because there are so many programmers with VisualBasic (or worse) background that don't see the benefits of OOP. Iterators and delegation via interceptors are cool !?!? You can do OOP since PHP 3. PHP 5 OOP improvements are nice but they will not make anybody richer. The OOP features of PHP3 were nothing more than some kind of crippled That is not the point. The point is that you said that people using PHP 4 do not see the benefits of OOP, as if they cannot do OOP in PHP 4. The reality is that even in PHP 3 you can use benefit of OOP features such as encapsulation and inheritance. PHP 5 adds more OOP features, some copied from Java and Visual Basic, but that does not mean developers must use PHP 5 to do OOP. It is also curious that you mention Visual Basic as if you could not do OOP in Visual Basic either. Did you know that not only you can do OOP since a long time ago in Visual Basic, but also you can make object variable accesses be implicitly implemented with setter and getter functions like you can now in PHP 5? As a matter of fact I just read this interesting article named The Six Dumbest Ideas in Computer Security that demonstrates what I always knew that upgrading to the latest versions is often a bad idea. Read the point #6) Action is Better Than Inaction . http://www.ranum.com/security/computer_security/editorials/dumb/ Nice article. Read it myself a few days ago (wasn't the link featured on Slashdot? *g*). Delaying upgrades might be true for running systems. But there's nothing keeping you from running both PHP4 and PHP5 on the same machine for different projects. And if you start a project from scratch PHP5 is the way to go. In theory yes, in practice nobody starts projects from scratch. Usually you reuse class libraries that are proven and implement many basic function. Many of those class libraries were built for PHP 4, not for PHP 5. Some are complex and large. If you use them in PHP 5 with prior certification chances are that you may stumble in PHP 5 bugs and backwards incompatible changes that make such libraries not work properly. Then even your new projects may be affected. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
On Tue, September 13, 2005 7:50 pm, Manuel Lemos wrote: I also am a bit surprised for the tremendous lack of interest to upgrade to PHP 5. Ok, I expected that many people would not want to upgrade due to the nightmare of dealing with backwards incompatible changes, but I did not expect that the statistics would be so overwhealming. I think there are simply no must have features in PHP 5. It's being treated more like a minor incremental release -- something to be done when a NEW machine or application needs to be built/written. I guess this should ring a lot of bells for those that expect to develop products targetted to PHP 5, because the numbers seem to show that PHP 5 is a flop, despite PHP 5.0.0 was released more than 1 year ago. I don't think that makes PHP 5 a flop We had this same issue (and experience) when PHP3 - PHP4 came around. People held onto PHP3 a lot longer than the hard-core developers/users expected. There is so much FUD in upgrading, that crucial uses simply won't upgrade until more time passes with no bugs/issues. My webhost is building new boxes with PHP5 and leaving the old ones alone with PHP4 -- So his new clients get PHP5, and old sites aren't broken by any of the rare incompatibilities. Some of my sites are on 5. Some are on 4. I can't tell a difference. That's a Good Thing in that PHP5 *IS* that backwards compatible. It's a Bad Thing in that I'm not gonna bug my host to upgrade or move my sites to PHP5, since I can't even notice a difference. 'Course I got zero interest in PHP OOP, XML, and any of the new features of PHP5 anyway, so I might be the exception. But webhosts will move to 5 when their clients demand it, not the other way around. For sure, getting RedHat (et al) to move to PHP5 for default install is the first big crucial step. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Manuel Lemos schrieb: In theory those are the only changes. In practice, besides the officially admitted changes, there are also the bugs that were not yet discovered or fixed. Examples? Links? More information on this? The fact is that on http://bugs.php.net/ A reference where _I_ have to search is something like a non-answer... php.internals there are discussions to reduce the number of maintained development threads. In the not-so-far future they will reduce the manpower put into backporting bugfixes to the PHP4.x development branch since 5.x is the HEAD revision and everything is first fixed there. I In theory yes, in practice no. As a matter of fact PHP 4.4 was introduced after PHP 5.0, although the new version, new bugs is the same. PHP 4.4.0 is dated 11-Jul-2005 and kind of a -break-stuff version (the reference notice). PHP 5.0.5 is a bit late here (05-Sep-2005) but it fixes about two times as many bugs AND inbetween there has been the RC1 of PHP 5.1. Speaking of releases it seems true that The 4.x branch is quicker but looking at php.internals one can see that the people there fix it in the HEAD revision and then complain about having to backport fixes to the other branches and they want to get rid of this by just backporting _serious_ fixes. think all old stuff is just as mature in PHP5 as you know it from PHP4 and if some errors are found they are likely to be fixed more quickly for the 5.x release. The new stuff (that wasn't there before 5.0) almost certainly has more bugs since it's younger but that's no argument since this isn't relevant for old projects. Right, that is why most people with old projects will not upgrade to PHP 5. I've got PHP5 and 4 running on the same machine. [OO bologna] That is not the point. The point is that you said that people using PHP 4 do not see the benefits of OOP, as if they cannot do OOP in PHP 4. No, I said that those people have a pre-PHP background that keeps them from seeing any use for OOP at all. The procedural programming paradigma is so clean and simple because it doesn't deal with larger concepts like abstract datatypes and their methods. One can quicker start doing stuff: some simple variable types, functions to manipulate them, that's it. On the other side, there's object orientation. The datatypes are alive, they can do things themselves. Then there are interfaces, contracts about using things so that you can use different datatypes in the same way. And so on and so on. All this are more complex concepts that a programmer only realizes with the right background. And a lot of the PHP programmers come from non-OOP languages or start programming in PHP with no background at all. Even (and this is not the main, but a subpoint) in the pre-PHP5 era PHP had some kind of OOP but was not evangelising its use. The reality is that even in PHP 3 you can use benefit of OOP features such as encapsulation and inheritance. PHP 5 adds more OOP features, some copied from Java and Visual Basic, but that does not mean developers must use PHP 5 to do OOP. That depends on how one defines OOP. Some people are satisfied with what PHP3 offered, other people say that even PHP5 is not featuring some of the most important features (like namespaces or proper overloading of method prototypes without manually parsing the parameter array). For me, destructors and delegation (or multiple inheritance) are important points for an object oriented language. On the opposite, I don't like exceptions because I hate the jumping around in the code. So everyone has different expectations of OOP. It is also curious that you mention Visual Basic as if you could not do OOP in Visual Basic either. Did you know that not only you can do OOP since a long time ago in Visual Basic, but also you can make object variable accesses be implicitly implemented with setter and getter functions like you can now in PHP 5? I just refer to VisualBasic because some of the most ugly code I have ever seen is Visual Basic code. I might as well have mentioned Perl. Perl features a complete OOP implementation but it's such an ugly thing that the ordinary Java programmer would simply commit suicide if forced to use it. [scratch vs reuse] In theory yes, in practice nobody starts projects from scratch. Usually you reuse class libraries that are proven and implement many basic function. Many of those class libraries were built for PHP 4, not for PHP 5. Some are complex and large. If you use them in PHP 5 with prior certification chances are that you may stumble in PHP 5 bugs and backwards incompatible changes that make such libraries not work properly. Then even your new projects may be affected. First of all, in many cases code reuse still is a myth. I hate to say it but it's true. Then, a large potion of the PHP community hasn't even heard of PEAR. Then, people definitely start projects from scratch. If they didn't, there would be no PHPUnit2, Creole or
Re: [PHP] Quick Poll: PHP 4 / 5
Richard Lynch schrieb: [...] Some of my sites are on 5. Some are on 4. I can't tell a difference. That's what I am evangelising. People seem very concerned about backward compatibility issues that _almost_ never come up (hell, the problems of PHP 4.3.x - 4.4 are more serious than 4-5!). People who are privately setting up a new machine should just go for the 5. Small hosting companies should do just like you told: keep the old ones on 4, go for 5 with new machines. And then there are large hosting companies who just feature all flavors of PHP on the same machine, easily switchable via .htaccess on a per-directory-basis. AllOLLi It's redundant! It's redundant! [R. E. Dundant] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hey everyone, I'm the original guy who started this thread, now that it has taken a totally different curve from what I originally wrote, kindly dont forward your reply to me and the list, the discussion is good though,I just dont need two copies of it :-) Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
On Tuesday 13 September 2005 05:52 pm, Ryan A wrote: [x] I never work with PHP 4 anymore, all my work is with PHP 5 so far I've not found any hosts that do PHP5, however I do all my own hosting anyway. I've switched to use PHP5 because I was interested in doing XSL, and the concept of doing objects intrigues me. XSL support in 5 is far superior. It's a walk in the park now, where as before it was quite confusing. I'm currently doing a project where the client doesn't know what she wants... because of this I'm constantly having to redo sections to add what she wants. So taking this approach for this client has saved me from 10 times more work. I personally can't wait for PDO. I do lots of projects that all use SQL (SQLite, PostgreSQL and MySQL) Right now I have to recode everything to use the right DB. with my newest project I'm using SQLite with a custom Object to handle the DB Object. It's actually design with PDO in mind. After they get PDO in and working well It'll save me hours of work. From that Website about the 6 dumbest ideas. I guess you could say I'm an early adopter I like ideas that'll save me time in the long run, even if I'm the one that has to do tons of testing to make it usable. The long run is what matters to me. If I can spend time learning, testing.. and then later be able to do something in 5 mins that'd take 15 the old way.. I'm up for it. Has to be someone to do the testing to bring projects forward isn't there ? ;) From the opposite side of the spectrum I have had my share of upgrade issues. One was from 5.0.4 to 5.0.5 $this-urlArr[0] = array_pop($arr = explode(,$this-urlArr[0])); I still have to scratch my head as to why I *need* that $arr = prior to 5.0.5 this was not needed. $this-urlArr[0] = array_pop(explode(,$this-urlArr[0])); Perhaps someone here could tell me what was change to make this happen.. and how does that change make the engine better? It seemed to work perfectly fine before. I've also had to upgrade a few classes written for PHP4 specifically ones that like to use: var $variable; Overall, If you can upgrade to 5 .. do so. the advantages in my cases have been so nice. If you can't upgrade, Don't. Use what works. I personally would urge you to upgrade to 5 if you wanna get in deep with objects. I'm sure that 3 and 4 can do them just fine. but whats the use of learning how to do OOP in something that has been updated? Or worded differently, Why learn old ways when you can benefit from newer ideas/implementations ? It'd be like putting logs under a platform and repositioning the log that came out the back in the front again as a way to move something instead of wagon just because it's always worked before. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hello, on 09/14/2005 08:20 PM Richard Lynch said the following: On Tue, September 13, 2005 7:50 pm, Manuel Lemos wrote: I also am a bit surprised for the tremendous lack of interest to upgrade to PHP 5. Ok, I expected that many people would not want to upgrade due to the nightmare of dealing with backwards incompatible changes, but I did not expect that the statistics would be so overwhealming. I think there are simply no must have features in PHP 5. I tend to agree, but I am not neglecting the fact that PHP 5 is still an improvement over PHP 4. I guess this should ring a lot of bells for those that expect to develop products targetted to PHP 5, because the numbers seem to show that PHP 5 is a flop, despite PHP 5.0.0 was released more than 1 year ago. I don't think that makes PHP 5 a flop I think that after one year since 5.0.0 release, only 3.5% of the hosts are is a fact that demonstrates that PHP 5 is a flop in terms of adoption as it does not seem to be compelling enough. We had this same issue (and experience) when PHP3 - PHP4 came around. I do not think the vast majority of people waited more than 1 year since PHP 4.0.0 to migrate. PHP 4 improvements over PHP were much more compelling because it was very easy to explain that PHP 4 was several times faster to run than PHP 3. PHP 5 does not seem to be any faster. In some cases PHP 5 is even slower than because now it has to check at runtime whether object variables can be accessed due to the private/public properties. Most of other arguments pro-PHP 5 are not easy to explain and persuade current PHP 4 users. There is so much FUD in upgrading, that crucial uses simply won't upgrade until more time passes with no bugs/issues. True, but PHP 5 FUD did not come out of nowhere. Many host companies know that making any sort of PHP upgrade (regardles to whatever version) can be a nightmare to their clients and their business because several PHP 4 releases have broken compatibility several times. I think the worst was when register_globals was disabled by default in php.ini . Sure, hosts could upgrade and keep register_globals on to not break their clients applications, but there were reported security holes fixed in newer versions and at same time the doomsayers where preaching that keeping register_globals on is a bad security sin, which a totally ridiculous claim, but hosts did not want to take chances and upgraded their client sites, causing major backwards incompatibily havoc. The consequence of that is once burned, twice shy. Now, you still have an hard time to convince any hosts to upgrade because they do not want to loose so much business again. My webhost is building new boxes with PHP5 and leaving the old ones alone with PHP4 -- So his new clients get PHP5, and old sites aren't broken by any of the rare incompatibilities. Some of my sites are on 5. Some are on 4. I can't tell a difference. That's a Good Thing in that PHP5 *IS* that backwards compatible. Not totally. That is a documented fact. It's a Bad Thing in that I'm not gonna bug my host to upgrade or move my sites to PHP5, since I can't even notice a difference. Right, that is what I said above regarding the lack of compelling reasons to upgrade. 'Course I got zero interest in PHP OOP, XML, and any of the new features of PHP5 anyway, so I might be the exception. I do not think you are the exception. Most new OOP feature were meant to please the Java lovers. Many of us are not Java lovers, or else we would probably using Java instead of using PHP cloned to look like Java. But webhosts will move to 5 when their clients demand it, not the other way around. Right, but I would fix your sentence a bit: webhosts will move to 5 when *enough* their clients demand it. The point is there are not so many clients demanding it, or else I am sure that the PHP4-95% vs. PHP5-3.5% odds would be different by now. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hello, on 09/14/2005 08:26 PM Oliver Grätz said the following: In theory those are the only changes. In practice, besides the officially admitted changes, there are also the bugs that were not yet discovered or fixed. Examples? Links? More information on this? The fact is that on http://bugs.php.net/ A reference where _I_ have to search is something like a non-answer... If you try searching the bug database for PHP 4 versus PHP 5 opened bug reports you will get your answer. php.internals there are discussions to reduce the number of maintained development threads. In the not-so-far future they will reduce the manpower put into backporting bugfixes to the PHP4.x development branch since 5.x is the HEAD revision and everything is first fixed there. I In theory yes, in practice no. As a matter of fact PHP 4.4 was introduced after PHP 5.0, although the new version, new bugs is the same. PHP 4.4.0 is dated 11-Jul-2005 and kind of a -break-stuff version (the reference notice). PHP 5.0.5 is a bit late here (05-Sep-2005) but it fixes about two times as many bugs AND inbetween there has been the RC1 In case it was not clear for you, what I am saying is not the matter is PHP 4.x vs. PHP 5.x, but rather upgrading vs. not upgrading. of PHP 5.1. Speaking of releases it seems true that The 4.x branch is quicker but looking at php.internals one can see that the people there fix it in the HEAD revision and then complain about having to backport fixes to the other branches and they want to get rid of this by just backporting _serious_ fixes. BTW, HEAD is PHP 6 now, not PHP 5.x anymore. think all old stuff is just as mature in PHP5 as you know it from PHP4 and if some errors are found they are likely to be fixed more quickly for the 5.x release. The new stuff (that wasn't there before 5.0) almost certainly has more bugs since it's younger but that's no argument since this isn't relevant for old projects. Right, that is why most people with old projects will not upgrade to PHP 5. I've got PHP5 and 4 running on the same machine. I just do not get why you still run PHP 4 when you are so confident that PHP 5 is the right version to use. [scratch vs reuse] In theory yes, in practice nobody starts projects from scratch. Usually you reuse class libraries that are proven and implement many basic function. Many of those class libraries were built for PHP 4, not for PHP 5. Some are complex and large. If you use them in PHP 5 with prior certification chances are that you may stumble in PHP 5 bugs and backwards incompatible changes that make such libraries not work properly. Then even your new projects may be affected. First of all, in many cases code reuse still is a myth. I hate to say it but it's true. Then, a large potion of the PHP community hasn't even heard of PEAR. Then, people definitely start projects from scratch. If You don't know if you have any numbers to back the large portion of the PHP community claim. Anyway, as the developer of phpclasses.org, the largest PHP class repository, I can inform you that the site has accumulated near 270,000 subscriber since 1999, of which at least half of them are considered active as you may verify here: http://www.phpclasses.org/browse/statistics/statistics.html The site has 2,200 approved packages but only 71 are PHP 5 specific. That is a lot of people reusing a lot of public class libraries! they didn't, there would be no PHPUnit2, Creole or Propel. And last but not least: Practically all PEAR stuff is written for PHP4 but does in fact work with PHP5 without problems. This is the case because the usual problems with PHP5 are almost never caused by real incompatibilities but by code that was wrong before (like those reference passing problems) and PHP5 is the language to report this as wrong. You are assuming that I mean that class libraries are necessarily the public ones. Even if I just meant the public ones available on PEAR, here you can see that there are 166 opened bug reports specific to PHP 5. Given this, it is hard to back your claim that these public class libraries all work well under PHP 5. http://pear.php.net/bugs/search.php?cmd=displaystatus=Openphpver=5 -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Quick Poll: PHP 4 / 5
Hi, I work for a company that makes websites and does custom programming for private indviduals and companies, I also freelance (like many on this list) I'm a bit curious, so far I have had no need to upgrade my skills or use the slightly different format / functions of PHP 5.x.infact I have not seen all that many hosts actually having support for it, so I thought of this little poll :-) Simply cross all the boxes that applies and reply to the list (along with your name on top) eg: [x] blah blah [] I am still working on PHP 4 [] I never work with PHP 4 anymore, all my work is with PHP 5 [] Oops, call me old fashioned but i am still with 3! [] I have no problems finding a host with PHP 5 support [] I can handle PHP 5, but I only work with PHP 4 [] Nah, will wait till PHP 6 is out, theres not much diff between 4 and 5 [] PHP 5 sounds / looks too hard to learn [] Other As for the Other box, well, this poll can hardly be close to perfect as i thought of it while writing this, so add your own comment there if you want :-) Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Ryan A wrote: I'm a bit curious, so far I have had no need to upgrade my skills or use the slightly different format / functions of PHP 5.x.infact I have not seen all that many hosts actually having support for it, so I thought of this little poll :-) [x] blah blah Don't think you'll get anything out of this. A reasonable person would not make a choice based on this poll, since it is biased. I could do a lot of work in Sun StarOffice, but somehow, others have upgraded to OO.org, can you tell me why? It's not that they don't have more then enough features in StarOffice to do their daily job successfully... Any PHP developer has to choose for herself will she use PHP 4 or 5... This has been throughly debated on this list. PHP4 has it's purposes, and any PHP developer would be nuts to abandon it completely. The support for PHP4 related problems will diminish eventually... PHP 5 is new and better, but it doesn't force you to write better code or OO code. That decision is yours, but there is no point not to switch to PHP5 for new projects. Rewriting small parts of PHP4 to make it PHP5 compatible (if they're not already) can be a great practice to learn PHP5 quirks and get up to speed with it. If you can't find a PHP5 hosting service, you obviously haven't even looked. Pick any PHP magazine, and you'll see at least 5 of them. Google a bit, you can't miss them. And if I were you, I'd never say I have had no need to upgrade my skills. At your (probably young) age, its dangerous. You're upgrading your skills for yourself, not for your clients! For starters, familiarize yourself with code refactoring :) bye, N:: smime.p7s Description: S/MIME Cryptographic Signature
Re: [PHP] Quick Poll: PHP 4 / 5
Hey all, Hehe, sorry, didnt mean to ruffle anyones feathersjust reply to me and not the list if you want to. Thanks to everyone who replied, esp those like Manuel Lemos who wrote a pretty long explanation for his reasons, as did [EMAIL PROTECTED] (sorry mate, you didnt leave your name in the email) Dont get me wrong, both the above emails were very good reading but I dont think both were forwarded to me and the list, if anyones interested I can forward it to them. Manuel also gave me a very good link: http://www.nexen.net/interview/index.php?id=49 although the percentages there might not be totally accurate as is today, coz that may have been a survey some time back, dont know for sure as I dont understand the language its written in...but the charts are kinda easy to understand. Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hello, on 09/13/2005 09:54 PM Ryan A said the following: Manuel also gave me a very good link: http://www.nexen.net/interview/index.php?id=49 although the percentages there might not be totally accurate as is today, coz that may have been a survey some time back, dont know for sure as I dont understand the language its written in...but the charts are kinda easy to understand. It is in French but it says there the statistics are from July 2005, so it is pretty recent. I also am a bit surprised for the tremendous lack of interest to upgrade to PHP 5. Ok, I expected that many people would not want to upgrade due to the nightmare of dealing with backwards incompatible changes, but I did not expect that the statistics would be so overwhealming. I guess this should ring a lot of bells for those that expect to develop products targetted to PHP 5, because the numbers seem to show that PHP 5 is a flop, despite PHP 5.0.0 was released more than 1 year ago. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Manuel Lemos wrote: I guess this should ring a lot of bells for those that expect to develop products targetted to PHP 5, because the numbers seem to show that PHP 5 is a flop, despite PHP 5.0.0 was released more than 1 year ago. I think it points more to hosting providers who don't want to force their clients to ensure their sites are php5 compatible. I'm sure if a client were to ask they would host them on a machine with php5, but if they are already on one with php4 they won't rock your boat. Hosting providers, which account for the vast majority of hosted domains, are pretty conservative. Personally, SimpleXML was all I needed to switch after a particularly frustrating bought with php4 and xml parsing. - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Always this stuff about breaking backward compatibility. People seem to think that the change from 4 to 5 means such a lot. In fact the changes from PHP4.0 to PHP4.4 are much more numerous. The backwarr incompatible changes between 4 and 5 fit on asingle page of screen: http://de.php.net/manual/en/migration5.incompatible.php And most of these changes don't affect the normal programmer. I think the change from 4 to 5 ist that slow because there are so many programmers with VisualBasic (or worse) background that don't see the benefits of OOP. Iterators and delegation via interceptors are cool concepts but to use them you have to learn how to use them. And before you learn how to use them you have to understand what they're for and why they're cool. And before that you have to know that such things even exist. And with questions like How do I increment by more than one in a for loop on the forum this isn't very likely to be the case for a majority of the PHP community. It's a very big community with some experts and a lot of total beginners. And a beginner likes to stick with what works for him. I guess we'll have to wait for the hosters to adopt PHP5 and then for the next generation of PHP beginners. They will not know that there was PHP4 when they begin to learn. For example, they will use PDO for database access right from the start and intuitively use the iterator of PDOStatement. AllOLLi When you can't fix the problem, point it out and pretend it was intentional. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Ben schrieb: [...] Hosting providers, which account for the vast majority of hosted domains, are pretty conservative. In Germany they're no that conservative. One of the biggest hosters in Germany (several million domains) allows to chosse between PHP 3, 4.0.6 4.3.x and 5.x via .htaccess Personally, SimpleXML was all I needed to switch after a particularly frustrating bought with php4 and xml parsing. SimpleXML is a good point. How could I forget it didn't exits with PHP4? AllOLLi Space: It seems to go on and on forever... [Futurama 101] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hello, on 09/13/2005 10:39 PM Ben said the following: I guess this should ring a lot of bells for those that expect to develop products targetted to PHP 5, because the numbers seem to show that PHP 5 is a flop, despite PHP 5.0.0 was released more than 1 year ago. I think it points more to hosting providers who don't want to force their clients to ensure their sites are php5 compatible. I'm sure if a client were to ask they would host them on a machine with php5, but if they are already on one with php4 they won't rock your boat. Hosting providers, which account for the vast majority of hosted domains, are pretty conservative. Right, but the problem all boils down to one matter: money! What happens is that many hosts have hundreds (to not say thousands) of clients hosted per server. If they upgrade the PHP version, chances are that they may break the applications of many clients. Displeased clients leave and they loose business. Therefore hosts are absolutely right in not messing with the servers of the customers that are pleased with their current setup, or else it will hurt their pockets big time! OTOH clients that have their sites working fine and dandy with current PHP version have no reason to change, unless what they may gain can justify the headache of asking to switch to a server with the PHP version of their choice or switch to another host that provides it. It seems that PHP 5 is not that much compelling to most people to justify the change. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
Hello, on 09/13/2005 10:46 PM Oliver Grätz said the following: Always this stuff about breaking backward compatibility. People seem to think that the change from 4 to 5 means such a lot. In fact the changes from PHP4.0 to PHP4.4 are much more numerous. The backwarr incompatible changes between 4 and 5 fit on asingle page of screen: http://de.php.net/manual/en/migration5.incompatible.php And most of these changes don't affect the normal programmer. In theory those are the only changes. In practice, besides the officially admitted changes, there are also the bugs that were not yet discovered or fixed. I think the change from 4 to 5 ist that slow because there are so many programmers with VisualBasic (or worse) background that don't see the benefits of OOP. Iterators and delegation via interceptors are cool !?!? You can do OOP since PHP 3. PHP 5 OOP improvements are nice but they will not make anybody richer . I do not think the problem is PHP 4 vs. 5, but rather upgrading to a new version a deal with known and unknown changes vs. not upgrading and keep sites working as before. It's a very big community with some experts and a lot of total beginners. And a beginner likes to stick with what works for him. I do not think this is a beginners problem. As a matter of fact begginners are more likely to naively jump to newer versions just to ride on the top of the latest wave. More experience developers are the ones that tend to be wiser not delay upgrades because they know that new versions have new bugs. As a matter of fact I just read this interesting article named The Six Dumbest Ideas in Computer Security that demonstrates what I always knew that upgrading to the latest versions is often a bad idea. Read the point #6) Action is Better Than Inaction . http://www.ranum.com/security/computer_security/editorials/dumb/ -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Quick Poll: PHP 4 / 5
It seems that PHP 5 is not that much compelling to most people to justify the change. I'm sure you're right, but I also think it's a question of work load for the ISP. Many server upgrades don't occur unless it's urgent and even then they sometimes get missed. Plus... the last time I went to lease a server, the ISP told me that RedHat didn't come with PHP 5. Installing PHP 5 was at my own risk. Maybe PHP 5 is now bundled with the latest version of PHP, but I know it wasn't for a while and I also know that this hampered PHP 5 getting out there. Is it possible to install both PHP 4 and PHP 5 on a single web server, have scripts all use the php extension, and somehow specify in the script itself which version of PHP should be used? -Ed
