Hello all.. I found a db app id like to use but:) it needs php 5 or greater im using suse 10.0 with php4.4.0 my question(s) : is it as simple as just finding one upgrade rpm? do apps that are now running with php4 break when i install 5? i've done some googling on it but my biggest fear of breaking what is working now i cant seem to find an answer for. thanks for any advice!
On Monday 11 September 2006 12:24, teck wrote:
my question(s) : is it as simple as just finding one upgrade rpm? do apps that are now running with php4 break when i install 5?
Yes, apps which are written for php4 may indeed fail with php5. The handling of object references was fundamentally changed between php4 and php5. Also, the support for object constructors is broken in php5 (meaning they changed it from the perfectly fine mechanism in php4 to some absolutely brain-dead mechanism in php5). If your php4 application takes special care to pass objects by reference then you will get lots of warnings with php5 because in php5 all objects are passed by reference (in php4 they are passed by value unless you explicitely use the pass-by-reference support). i have had several applications break because of this, but fixing them wasn't too much work (assuming you know what you're looking for). O'Reilly has a really helpful book about upgrading from php4 to php5, and what changes (read: breakage) is likely to happen between them. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
On Monday 11 September 2006 13:02, stephan beal wrote:
On Monday 11 September 2006 12:24, teck wrote:
my question(s) : is it as simple as just finding one upgrade rpm? do apps that are now running with php4 break when i install 5?
Yes, apps which are written for php4 may indeed fail with php5. The handling of object references was fundamentally changed between php4 and php5. Also, the support for object constructors is broken in php5 (meaning they changed it from the perfectly fine mechanism in php4 to some absolutely brain-dead mechanism in php5).
The old mechanism should still work in php5. In fact, the name of the constructor is either the class name (old way), or the special name __constructor (new way). To me this seems only a name-change. Where does this brain-dead-ness come from?
If your php4 application takes special care to pass objects by reference then you will get lots of warnings with php5 because in php5 all objects are passed by reference (in php4 they are passed by value unless you explicitely use the pass-by-reference support).
You will get a warning too if your code refers to an uninitialized/unknown variable. Much better, but a bit of a PITA to "fix". ;P Cheers, Leen
On Monday 11 September 2006 15:09, Leendert Meyer wrote:
The old mechanism should still work in php5. In fact, the name of the constructor is either the class name (old way), or the special name __constructor (new way). To me this seems only a name-change. Where does this brain-dead-ness come from?
The old mechanism does work but is deprecated and may give a warning. The brain-dead way is them renaming the ctor to __constructor(). This is against the convention of every programming language known to man. The argument for the change was "because you could break subclasses by renamig the parent class, so we make this impossible by making the paren't ctor name the same no matter what you call your class." That's a completely B.S. argument, though, because the "extends" statement still has to name the base class. So now it's possible to rename parent classes... and still break the child class when doing so. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
On Monday 11 September 2006 17:02, stephan beal wrote:
On Monday 11 September 2006 15:09, Leendert Meyer wrote:
The old mechanism should still work in php5. In fact, the name of the constructor is either the class name (old way), or the special name __constructor (new way). To me this seems only a name-change. Where does this brain-dead-ness come from?
The old mechanism does work but is deprecated and may give a warning. The brain-dead way is them renaming the ctor to __constructor(). This is against the convention of every programming language known to man. The argument for the change was "because you could break subclasses by renamig the parent class,
I think things could break if the parent class were renamed without renaming the constructor (with the same name), because the constructor would be called automatically if it has the same name as its class. Right?
so we make this impossible by making the paren't ctor name the same no matter what you call your class." That's a completely B.S. argument, though, because the "extends" statement still has to name the base class.
Of course. One would have to change the class name in the "extends" statement too.
So now it's possible to rename parent classes...
Yes, ...
and still break the child class when doing so.
Here I can't follow you. The child class would call parent::__construct() in its __construct(). In php4 that would be parent::<Parent_Class_Name>(). Renaming the parent breaks the child in the "extends" statement and the constructor in php4, and only the "extends" statement in php5. Right? Cheers, Leen
On Monday 11 September 2006 21:57, Leendert Meyer wrote:
I think things could break if the parent class were renamed without renaming the constructor (with the same name), because the constructor would be called automatically if it has the same name as its class. Right?
The parent ctor was not (in php4) called automatically. Maybe it is in php5 - don't know for sure.
Here I can't follow you. The child class would call parent::__construct() in its __construct(). In php4 that would be parent::<Parent_Class_Name>().
Right, but the PHP team's argument for renaming the ctor from ParentClass to __constructor was "because subclasses can be broken by renaming the parent class." This behaviour applies to any OO language, and was not a valid reason to rename the ctors, IMO. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
On Tuesday 12 September 2006 09:04, stephan beal wrote:
On Monday 11 September 2006 21:57, Leendert Meyer wrote:
I think things could break if the parent class were renamed without renaming the constructor (with the same name), because the constructor would be called automatically if it has the same name as its class. Right?
The parent ctor was not (in php4) called automatically. Maybe it is in php5 - don't know for sure.
php4: http://www.php.net/manual/en/language.oop.constructor.php, 1st line. In short: they /are/ called automatically. php5: http://www.php.net/manual/en/language.oop5.decon.php, 2nd + 3rd line. In short: they /are/ called automatically too.
Here I can't follow you. The child class would call parent::__construct() in its __construct(). In php4 that would be parent::<Parent_Class_Name>().
Right, but the PHP team's argument for renaming the ctor from ParentClass to __constructor was "because subclasses can be broken by renaming the parent class." This behaviour applies to any OO language, and was not a valid reason to rename the ctors, IMO.
It's rather fuzzy; I'm curious what they exactly mean with that. Cheers, Leen
On Tuesday 12 September 2006 15:16, Leendert Meyer wrote:
php4: http://www.php.net/manual/en/language.oop.constructor.php, 1st line. In short: they /are/ called automatically.
Correction: "If a class has no constructor, the constructor of the base class will be called, if it exists." They go on to say, way down near the bottom: "PHP 4 doesn't call constructors of the base class automatically from a constructor of a derived class. It is your responsibility to propagate the call to constructors upstream where appropriate."
It's rather fuzzy; I'm curious what they exactly mean with that.
Dunno, i read it in an O'Reilly book. The link you sent hints at it, though: "The function B() in class A will suddenly become a constructor in class B, although it was never intended to be. PHP 4 does not care if the function is being defined in class B, or if it has been inherited." By renaming the ctors to __constructor, this problem never happens. Seems to be a lame workaround, though. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
On Tuesday 12 September 2006 18:41, stephan beal wrote:
On Tuesday 12 September 2006 15:16, Leendert Meyer wrote:
php4: http://www.php.net/manual/en/language.oop.constructor.php, 1st line. In short: they /are/ called automatically.
Correction:
It's more an addition. :)
"If a class has no constructor, the constructor of the base class will be called, if it exists."
They go on to say, way down near the bottom:
"PHP 4 doesn't call constructors of the base class automatically from a constructor of a derived class. It is your responsibility to propagate the call to constructors upstream where appropriate."
As it is the case in php5.
It's rather fuzzy; I'm curious what they exactly mean with that.
Dunno, i read it in an O'Reilly book. The link you sent hints at it, though:
"The function B() in class A will suddenly become a constructor in class B, although it was never intended to be. PHP 4 does not care if the function is being defined in class B, or if it has been inherited."
This is the interesting part, which I "kind of" knew, but frankly spoken did not think about: "promotion" (well, sort of...) of a function to a constructor. Hmm, seems to me that php5 solved this issue.
By renaming the ctors to __constructor, this problem never happens.
Indeed.
Seems to be a lame workaround, though.
Lame? Why? Cheers, Leen
participants (3)
-
Leendert Meyer -
stephan beal -
teck