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

[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" <liquidlaughter2000@blueyonder.co.uk> schrieb im Newsbeitrag
news:UMEPa.949$uO5.728@news-binary.blueyonder.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
>

[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" <liquidlaughter2000@blueyonder.co.uk> schrieb im Newsbeitrag
news:UMEPa.949$uO5.728@news-binary.blueyonder.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.

[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{$index} or something
of that nature. Do you recall if that was implemented?

// Ian

[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{$index} or something
of that nature. Do you recall if that was implemented?

// Ian

[Agelmar]

"Keith Maika" <slick@aoeex.com> wrote in message
news:vh11pgc5evdf0d@corp.supernews.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{$index} 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{$index} 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]

"Keith Maika" <slick@aoeex.com> wrote in message
news:vh11pgc5evdf0d@corp.supernews.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{$index} 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{$index} 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" <slick@aoeex.com> wrote in message
> news:vh11pgc5evdf0d@corp.supernews.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{$index} 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{$index} 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" <slick@aoeex.com> wrote in message
> news:vh11pgc5evdf0d@corp.supernews.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{$index} 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{$index} 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:

> 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...

[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...