Upgrade to PHP5 (beta)

[Christoph Nothdurfter]

Hallo!

I was wondering if my PHP4-Scripts will run under PHP5 (Haeven't tried the
beta yet).
Does anybody know?

Thank you,
-Christoph

[Peter Matheis]

> "Will PHP 5 break backwards compatibility?"

"No, the main functionality will stay the same, but since PHP 5
adds many more object-oriented features and tools,
it will cause some of the older scripts using PHP 4.x to break."
For more information look at "http://www.zend.com/php/ask_experts.php "

Peter

"MeerKat" <li************ ****@blueyonder .co.uk> schrieb im Newsbeitrag
news:UM******** *******@news-binary.blueyond er.co.uk...

I was wondering if my PHP4-Scripts will run under PHP5
> (Haeven't tried the beta yet).

Yes. PHP is always very good at backward compatibility and there
*should* be no reason why they wouldn't work.

MK.

--
MeerKat

[Louis-Philippe Huberdeau]

Agelmar wrote:

MeerKat wrote:

I was wondering if my PHP4-Scripts will run under PHP5

> (Haeven't tried the beta yet).

Yes. PHP is always very good at backward compatibility and there
*should* be no reason why they wouldn't work.

MK.

I don't know that I'd quite go that far.... PHP is *usually* good at
backwards compatability. I can't even guess how much money I made fixing
scripts for companies when their IT-guys rolled out PHP 4.2.0, and that
wasn't even such a big thing.

Anyone remember anymore the change in if..endif syntax from PHP 2 to PHP 3?
that broke a lot...

PHP3 also used a new method to determine the type of a result... that caused
odd quirks...

And going from PHP3 to PHP4, man, I can't even remember how long it took me
to track down errors caused by empty("0") == true... same with $var = "",
isset($var) == true...

So while I would say that php is usually good about backwards compatability,
I would certainly not say always. Download PHP5, test it out (I checked out
a build from CVS back in April, and have been testing since then...), and
test out ALL your scripts THOROUGHLY. Make sure you have tested everything
with php5 for a while before moving into production with php5 when it comes
out. Personally, I will probably wait until 5.0.2 to roll out on my
production server.

Testing is mandatory...

(As for things that will break PHP5 - I'm trying to think... the MySQL libs
are no longer included, this might cause problems for people who dont read
readmes :-) Other than that, I'll sit back on the sidelines and watch for a
while before jumping on the production bandwagon ^-^
MySQL problem should be solved by then, and the mysqli lib is worth the
move.

// Ian Fette
// Proponent comp.lang.php

The only thing that will really break the scripts is if your script
required the implicit object copy. It's quite easy to fix using
__clone() tought.

Other than the way objects are handled, there are not that many
differences between PHP4 and 5, even if that change makes an entire new
language.

[Agelmar]

Louis-Philippe Huberdeau wrote:

MySQL problem should be solved by then, and the mysqli lib is worth
the
move.

mysqli is interesting, but requires MySQL >= 4.1.x. Most servers that I've
worked on lately are running 3.23.57 - I think the jump to 4 is a big change
for many sysadmins, and I don't forsee mysql4 taking over on most
development systems until at least 2004. Of those systems that I have worked
on that *are* running MySQL 4.x, they have been almost exclusively MySQL
4.0.x, usually 4.0.11. Currently, the production release is 4.0.13, an 4.1.0
is listed as alpha. I have yet to see a production server that I've been
hired to develop for run 4.1.x. So while I am a bit intrigued by mysqli, I
do not hold out a hope that it will solve the problems of removing the
bundled mysql lib. Hopefully they work something out, but I don't think
mysqli is the answer.

As for SQLite - this is an interesting development, however given that it's
currently primarily PHP 5.0.0 only, I don't forsee implementing it in my
work any time soon, especially given that it does not support ALTER TABLE. I
use ALTER TABLE frequently - for example, I just did a program for a client
that, among other things, tracked objectives and whether a certain item met
certain objectives. I have one table that contains the itemID and then a
field for each objective - when I the client adds objectives, this table is
ALTERed. So unless SQLite implements ALTER TABLE, I think I would only use
it in a very limited fashion.

// Ian Fette
// Proponent comp.lang.php

The only thing that will really break the scripts is if your script
required the implicit object copy. It's quite easy to fix using
__clone() tought.

Other than the way objects are handled, there are not that many
differences between PHP4 and 5, even if that change makes an entire
new language.

I seem to recall that they were proposing eliminating indexing into a string
via $somestring[$index], going for instead $somestring{$in dex} or something
of that nature. Do you recall if that was implemented?

// Ian

[Agelmar]

"Keith Maika" <sl***@aoeex.co m> wrote in message
news:vh******** ****@corp.super news.com...

Agelmar wrote:

Louis-Philippe Huberdeau wrote:

...

I seem to recall that they were proposing eliminating indexing into a string via $somestring[$index], going for instead $somestring{$in dex} or something of that nature. Do you recall if that was implemented?

// Ian

That has been done for a long time. Maybe they are finally going to
remove support for $something[$index] but it's been in the manual for
quite some time that they do not want you do use that syntax, and rather
$something{$ind ex} should be used.

Hmm... personally, I much prefer $something[$index] as it's closer to C, and
just feels more natural :-) No idea why they changed it $string{$index}
just feels like a concatenation of $string and $index... I mean come on,
you're indexing into the string, why drop the array subscripting? gah...

[Louis-Philippe Huberdeau]

Honestly, I never heard of that modification and have been following the
development for quite a while... and my square brackets still work just
fine.

Don't worry about that, chances they modify that part are very low. They
don't want to remove case insensitivity because it would cause
incompatibility issues, I can't even think of the disaster it would make
if they would change the array element symbol. It's about the most used
syntax of the entire language... except maybe the PHP tags.

Agelmar wrote:

"Keith Maika" <sl***@aoeex.co m> wrote in message
news:vh******** ****@corp.super news.com...

Agelmar wrote:

Louis-Philippe Huberdeau wrote:

...

I seem to recall that they were proposing eliminating indexing into a
string
via $somestring[$index], going for instead $somestring{$in dex} or
something
of that nature. Do you recall if that was implemented?

// Ian

That has been done for a long time. Maybe they are finally going to
remove support for $something[$index] but it's been in the manual for
quite some time that they do not want you do use that syntax, and rather
$something{$i ndex} should be used.

Hmm... personally, I much prefer $something[$index] as it's closer to C, and
just feels more natural :-) No idea why they changed it $string{$index}
just feels like a concatenation of $string and $index... I mean come on,
you're indexing into the string, why drop the array subscripting? gah...

[Agelmar]

Louis-Philippe Huberdeau wrote:

Honestly, I never heard of that modification and have been following
the development for quite a while... and my square brackets still
work just
fine.

Don't worry about that, chances they modify that part are very low.
They don't want to remove case insensitivity because it would cause
incompatibility issues, I can't even think of the disaster it would
make
if they would change the array element symbol. It's about the most
used syntax of the entire language... except maybe the PHP tags.

Not for indexing into arrays, only when indexing into a string as an array
to grab the ith character. [] remains the array index operator, but {} is
supposed to be used for strings.

wierd :(

[Agelmar]

Louis-Philippe Huberdeau wrote:

MySQL4.1 is still in development, and so is PHP5. Moving from MySQL3.x
to 4.x will not be that much of a major change since everything that
used to work still work. I run a dev version of php5 (pre-beta, didn't
have time to upgrade) and mysql4.1 alpha on my test server and the
standard mysql lib connects just fine with the MySQL server. Scripts
won't suffer from that change.

SQLLite will sure be a major part of PHP from now on. PHP developpers
wanted to seperate PHP and MySQL for a while since PHP can do a lot
more
and most seemed to forget it. MySQL is powerful but it's not the only
solution. PHP/MySQL is NOT a platform.

As for your alter table problem, you might want to review your basic
data architecture and use a relational table instead. You shouldn't
need
to modify a table structure that way all the time.

The tables are altered only when a new objective is added, which is very
rare. I would estimate it would happen perhaps once every three months at
the most. There are a list of objectives which are already defined from the
getgo, and these are quite comprehensive. The ability to modify this list is
provided simply for completeness, I doubt that it would be used very often.
relational tables seemed like overkill...