Is it safe to abandon PHP4 yet?

[Kilroy]

Okay, sure if I were writing brand new code, I might consider focusing it on PHP5. Only if, however, my current web host supported PHP5. I'm not going to change web hosts simply to get PHP5.

Why, however, should I have to go through tens of thousands of lines of code to get my PHP4 scripts to work on PHP5? There is no business sense to this. Rewriting code for PHP5 will not improve my profit margin nor will it decrease my costs. It only represents a major cost with no appreciable benefit.

For the most part, I love open source software. My website is hosted on a FreeBSD/Apache/PHP/MySQL server and I use Firefox. With that said, not making sure that PHP5 was backwards compatible with PHP4 or at least making sure it could run parallel to PHP4 was at the very least very stupid. Expecting everyone to jump to upgrade simply because it is an upgrade and the PHP developers say to jump is arrogant.

I certainly hope that the PHP developers learn from their mistakes with PHP5 and make sure that PHP6 plays nice with legacy code or at least plays nice with parallel installs of PHP4/PHP5. If they don't do this, it will fragment PHP support resulting in a balkanization of PHP.

Honestly, you shouldn't have to spend much time on converting at all. I agree that from a business point of view it does not seem very profitable at first. However, doing a few changes here and there (with 10,000 lines of code you shouldn't have to spend more than two days on it, I think probably even less) might make future development even easier.

[jayboots]

I still don't see the motive.
Web developers don't need it.
Thus Clients don't need it.
Thus Web hosts don't need it.

And it's not compatible with php4? It's suicide for making PHP 5.... It's useless and overrated. Sure a few new features, but why not just add that into php 4, this is NOT enough substance to make a whole new version!!!

Says you. It seems clear to me that no argument will persuade you. Fair enough -- especially since PHP4 continues to live on and is still maintained. As for adding in these new features into PHP4 -- have you considered that maybe it isn't possible? There are major version numbers for a reason. If you don't think improved tooling is worth the effort, then fine -- use what you like -- but don't assume that your logic works for everyone. Especially since the facts are different than your logic would dictate -- there *is* a PHP5 and there *are* ardent users of it who appreciate the extra conveniences and possibilities it affords them.

[Super Phil]

So what excatly in PHP4 is not compatible with 5? What specific functions work in 4 and not in 5?

It would be safe to say that most OO apps form PHP5 won't easily go back to PHP4.

Because once you start being OOP you loose sight of variables and even the most experienced web developer can make mistakes.

That is simply a reflection of your skill and not the style of development.

I still don't see the motive.
Web developers don't need it.
Thus Clients don't need it.
Thus Web hosts don't need it.

And it's not compatible with php4? It's suicide for making PHP 5.... It's useless and overrated. Sure a few new features, but why not just add that into php 4, this is NOT enough substance to make a whole new version!!!

According to you, for whom OOP is appareantly overcomplicated (since you loose track of variables). For anyone who does heavy XML lifting, or uses OOP in PHP (and, its worth saying that PHP5s OOP support is approaching a sense of completness. Yes, bugs remain, but its getting there) PHP5 is really worth it. (Exceptions, no silly &, etc etc)

[Selkirk]

PHP 3, PHP 4, and PHP 5 all have different object models. One could argue that the whole affair of using references for objects in PHP 4 was a dead end. But, now we have the object model we should have had and that won't change. Unfortunately, its a big change.

PHP will have the same object model from now on. I doubt the change from 5 to 6 will be as traumatic. Although, perhaps with the unicode stuff, some fundamental string manipulation stuff will break. I suspect that this stuff will be much easier to fix, however.

[Carl]

I still don't see the motive.
Web developers don't need it.
Thus Clients don't need it.
Thus Web hosts don't need it.

And it's not compatible with php4? It's suicide for making PHP 5.... It's useless and overrated. Sure a few new features, but why not just add that into php 4, this is NOT enough substance to make a whole new version!!!

LOL, you can call it whatever version number you want but php4 with php5 features is still not php4. The version number just makes it easy to identify when to look fo the new features. The addition of the new features would make you have to recode regardless. Just like going from php4.3 to 4.4. Granted the changes are more drastic from 4 to 5 but there are more features to consider.

[execute]

yes but the functions you have mentioned don't really interest me to switch all my coding, and recode my website for it. You haven't mentioned any new function that really saves a lot of time, except getting rid of the &s, which isn't that time consuming anyway. Of course it probably has it's uses, but not enough for me to switch versions.
Give me a function or method of coding that will actually do something that i cant do in PHP 4, and I'll switch over. OOP can be complicated in certain applications, and please do not take shots at my skill/style because it's childish, and i've been doing pHP for years. Please before you argue, try and take pHPbb code and make it OOP, I'm sure it'll be time consuming, and lots of bugs will come up.

[KLB]

Honestly, you shouldn't have to spend much time on converting at all. I agree that from a business point of view it does not seem very profitable at first. However, doing a few changes here and there (with 10,000 lines of code you shouldn't have to spend more than two days on it, I think probably even less) might make future development even easier.

I seriously doubt there would be a payback that was worth the initial trouble. Most of my code is very stable. My code does what I need so I have little need to update or add to the core code. For the most part, I only add new content to my websites, which doesn't require PHP programming. In order to take advantage of the new features in PHP5, I would have to spend time learning what they are and how to take advantage of them. I would then have to develop new programming practices to fully take advantage of the capabilities of PHP5. In all likelihood, this would entail a sizable learning curve.

If I did lots of PHP programming, there might be a payback for upgrading and learning new techniques. I do not; however, do a lot of PHP programming any more so there is little advantage to going through the expense of updating.

[Dr Livingston]

I do not; however, do a lot of PHP programming any more so there is little advantage to going through the expense of updating.

You don't, but a lot of other people do; A lot of other people are willing to take the first steps to move towards a better language.

If your not prepared to make the move, for whatever reason, then fair enough, that's your choice, but please do not bleat on about there being no advantage of a move, just because you do not see any benifits, immediate or otherwise.

If hosts are not prepared to adapt PHP5 then they are hurting developers short term, and they are hurting clients long term.

Execute,

Once you begin to develop moderately large scale applications, you will see without a doubt, the benifits of what PHP5 offers you over what PHP4 can.

Don't knock it.

[firepages]

So what excatly in PHP4 is not compatible with 5? What specific functions work in 4 and not in 5?

Its not so much that, its little changes like get_class and friends suddenly becoming case sensitive (that broke Horde BTW) $this can no longer be used as a variable name & perhpas it was always stupid to do so (or is that in hindsight) but that alone has broken a few apps.

Give me a function or method of coding that will actually do something that i cant do in PHP 4

SimpleXML is enough reason to switch, I dont much like XML and avoid where I can but when you have to use it , then the simplexml functions are lifesavers.


...................

Funny thing is I use Plesk on a couple of servers & Plesk reloaded runs on PHP5 ... but Plesk suggest that they dont provide PHP5 as part of Plesk since its not yet tested/stable ??? then again Plesk stores all user (and admin) passwords in plain text so what do you expect

I am having problems working out why this thread is going the way it is , each to thier own, live and let live etc, chill, there ARE compatibility issues between PHP4/5 and 6 is a self proclaimed BC no-no, but lets argue about that one instead

[firepages]

BTW regardless of functionality PHP5 is simply faster than PHP4 even with same-same code , so to ignore that seems counter-productive ?

[KLB]

If your not prepared to make the move, for whatever reason, then fair enough, that's your choice, but please do not bleat on about there being no advantage of a move, just because you do not see any benifits, immediate or otherwise.

This is a discussion on the pros or cons of choosing PHP4 vs. PHP5. Like others in this thread I am simply pointing out why I don't think the advantages of PHP5 outweigh the costs for most sites like mine. Just because this isn't what you want to hear or believe doesn't invalidate the position against upgrading. For some people the benefits of upgrading do out weigh the costs, however, for many people they do not as is evident by the fact that most people are not switching.

If hosts are not prepared to adapt PHP5 then they are hurting developers short term, and they are hurting clients long term.

Not necessarily. There may be absolutely no long term impact towards ignoring PHP5. In fact it may be much smarter to skip PHP5 all together and go straight to PHP6 once it has been completed.

The failure of web hosts to adopt PHP5 and the failure of web publishers like myself to demand PHP5 is not the lack of vision on our part, but rather the failure of PHP developers to understand some fundamental needs of web hosts and non-bleeding edge web developers and the failing of PHP developers to provide really compelling benefits to upgrading. That fundamental requirement web hosts and developers like my self have are seamless backwards compatibility and a seamless transition. PHP5 does not meet this requirement.

BTW regardless of functionality PHP5 is simply faster than PHP4 even with same-same code , so to ignore that seems counter-productive ?

It all depends on the amount of work it takes to go from PHP4 to PHP5. The performance payback may not be worthwhile if a site isn't having performance problems to begin with.

[lastcraft]

Hi...

This is the fatal flaw with PHP5. Had PHP developers been smart, they would have made sure that it was backwards compatible with PHP4 such that it could have been easily adopted without having to rework existing code.

I think it goes deeper. They should have released in smaller increments, like a good open source project. If PHP5 had just changed the references and nothing else, we would have less of this "big bang" upgrade problem and the forking to two versions. Adding interfaces, protected members, type hints, reflection and the kitchen sink slowed the release date and broke the upgrade rythym.

Big releases are damaging.

yours, Marcus

[Kilroy]

The failure of web hosts to adopt PHP5 and the failure of web publishers like myself to demand PHP5 is not the lack of vision on our part, but rather the failure of PHP developers to understand some fundamental needs of web hosts and non-bleeding edge web developers and the failing of PHP developers to provide really compelling benefits to upgrading. That fundamental requirement web hosts and developers like my self have are seamless backwards compatibility and a seamless transition. PHP5 does not meet this requirement.

The PHP developers had to make a choice. Many people were complaining about PHP, about things that needed to be improved, illogic function names that need to be taken out, etc. I agree with a lot of this criticism. To improve the language and get out these faults, backwards compatibility will break. There simply isn't a solution for this problem. If software (or a language) needs to be improved drastically, backwards compatibility must break. It needs to be broken sometime and the PHP developers thought now was the time.

[lastcraft]

Hi...

I also one that doesn't buy all the OO dogma that people try to sell us. I've done both procedural and OO and for most web projects(small and mid-size), I don't really see the "wonderful benefits" of OO that people are trying to sell.

This paragraph presents me with a problem. Partly because it's pretty much a FAQ, and I stopped replying OO v. procedural threads a while ago, but also because I don't know how to avoid coming across as arrogant. Bear with me...

I know a load of ex-Smalltalk Java developers. Smalltalk has blocks and closures which are missing from Java, but it turns out you can bend inner classes to produce something similar. These guys write Java code that I don't understand. They see an advantage to this style that I don't, one that makes their approach extremely powerful. They somehow manage to do a lot with not much code. They are a rung above me on that particular ladder. I don't miss this though, because I am just not aware of it. I can write stuff in Java and get there in the end, so until I see this stuff I think there is nothing new under the Sun (microsystems). Luckily I am aware something is up, so I'm learning some Ruby to explore further.

The Lisp/Scheme/Haskell crowd can do very clever on the fly language parsing tricks. They see no distinction between SAX parsing and DOM parsing for example, because they are doing something altogether higher order with macros/reducers type stuff. I just don't understand what they do. I can still parse XML, and if I wasn't aware that Lisp/Scheme/Haskell existed, I'd do it the same dumb way forever. I'm fine until shown that another world exists. As it happens, I am now looking at Haskell.

I bet this is true for rules engines and logic driven programming - the same for aspects and metaprogramming. I don't "need" it, because I know nothing about it. I can build everything with handtools, what do I need powertools for? As I get better with my handtools I have to think less, so I think things are becoming slightly faster. I am not a good enough programmer yet, I just think I am. All the while, I could force myself to think a little more, and suddenly find I could go a lot faster. I think this is the key. When you can write the code faster than you can think, you are missing something.

It's as if you are climbing a ladder into a cloud and you cannot see the next rung up. only the ones below you. You think you are always close to the top. You can probably tell where this is going...

The value in OO is in evolving an explicit model of the project domain. Coding hardcore OO is a process of learning about the business you are developing for. The programming kind of disappears into the background once you are fluent. If the OO model matches the problem, a feature gets added near instantly. If there is a mismatch you learn, correct the model, and feel one step closer to the problem. It's difficult to convey the joy of being "connected" to a problem domain and exploringthis new world. It's like trying to explain visual metaphors of a painting to a blind man, there is just no shared vocabulary.

So does OO allow you to write less code? For a single class/script you will have slightly more. However, the extra factoring power will allow you to collapse code on occasion as a more elegant model emerges.

Will your OO code go faster? For a single class/script it will be slightly slower. The ability to break your code down into chunks will allow you to easily add lazy evaluation, caching and compiled components. These types of change make oredr of magnitude performance changes, so yes, OO makes your code go faster.

Will OO make your code more correct? For small routine programs, no. A functional or data description is easier for the developer to understand. This means that the developer can develop the code in their head almost as they discuss requirements. At least for small problems. Unfortunately that approach breaks down completely for larger ones. With OO you expect to get it wrong, and then build the model as requirements come in. A slower start, but it soon starts to hum. Even by version 1 at least a third of the predesigned code will have been wrong. OO even has the benefit of building models in the same language as the business, aiding later comunication. So yes, OO does allow you to build more correct code.

Unfortunately, if you have never experienced this, then you won't see the point.

yours, Marcus

[Dr Livingston]

Quickly,

In fact it may be much smarter to skip PHP5 all together and go straight to PHP6 once it has been completed.

But who is to say that we won't be back here in 12 months or so with the exact same arguement with PHP6?

I might add that it will in all probability, be a lot easier to refactor from PHP5 to PHP6, than it would be from PHP4 to PHP6, simple because the object model between version 5 and 6 are identical;

Reading the recent PHP6 meeting, the object model has no changes, that would effect our PHP5 scripts.

[Ren]

I know a load of ex-Smalltalk Java developers. Smalltalk has blocks and closures which are missing from Java, but it turns out you can bend inner classes to produce something similar. These guys write Java code that I don't understand. They see an advantage to this style that I don't, one that makes their approach extremely powerful.

I always wonder why javascript/ecmascript never got going on the server, it a fairly neat language, has closures, single inheritance, etc etc. just no one ever seemed to have done it, and given the popularity of AJAX/JSON etc you'd think it'd be a winner.

PS. if anyone suggests using .net/mono & javascript.. its a crippled version of javascript

[Ren]

SimpleXML is enough reason to switch, I dont much like XML and avoid where I can but when you have to use it , then the simplexml functions are lifesavers.

Yeah, like the XmlReader & XmlWriter duo, very nice, expecting someone will write template engine with those pair soon enough.

[Selkirk]

But who is to say that we won't be back here in 12 months or so with the exact same arguement with PHP6?

PHP 5 breaks BC because it changed a fundamental aspect of the language: how parameters are passed. It is difficult to write code that works in both 4 and 5 because parameter passing is so fundamental.

PHP 6 is going to break BC because it will also change a fundamental aspect of the language: how the basic string type is handled. However, I suspect that writing code that works in both 5 and 6 will be easier than writing code that works in both 4 and 5.

In other words, I think it will be easier to write code that works in two different string paradigms, single byte versus UTF-8, which were designed to be compatible, than it is to write code that works in two different object models.

PHP 3: pass objects by value
PHP 4: pass objects by reference or value
PHP 5: pass objects by reference

[jayboots]

This is a discussion on the pros or cons of choosing PHP4 vs. PHP5. Like others in this thread I am simply pointing out why I don't think the advantages of PHP5 outweigh the costs for most sites like mine. Just because this isn't what you want to hear or believe doesn't invalidate the position against upgrading.

You already claimed that you don't program in PHP anymore. The original poster asked if it is time to start developing in PHP5 or not. From what I can tell, you are only saying "there is no point for me to recode my current site to PHP5 because I no longer use PHP" -- which is fine, except that I don't see how that relates to the thread.

The failure of web hosts to adopt PHP5 and the failure of web publishers like myself to demand PHP5 is not the lack of vision on our part, but rather the failure of PHP developers to understand some fundamental needs of web hosts and non-bleeding edge web developers and the failing of PHP developers to provide really compelling benefits to upgrading. That fundamental requirement web hosts and developers like my self have are seamless backwards compatibility and a seamless transition. PHP5 does not meet this requirement.

Yes, major versions typically entail work because of breakage. That's not surprising, is it?

[jayboots]

I think it goes deeper. They should have released in smaller increments, like a good open source project. If PHP5 had just changed the references and nothing else, we would have less of this "big bang" upgrade problem and the forking to two versions. Adding interfaces, protected members, type hints, reflection and the kitchen sink slowed the release date and broke the upgrade rythym.

Big releases are damaging.

No no no. That is plain wrong. One big release for lots of breakage is far better than many small breaks. I like to take my lumps once and for all, if possible. Somehow I thought that you had a similar sentiment in a previous thread regarding incremental breaks in the PHP5.0.x line some months back (?) BTW, I thought your previous post (#89) was very well done.

[Archbob]

So, what if you don't really use OO, then the switch from 4 to 5 should be fine right?

But then again, if you don't use OO, there's really no point in switching.

If PHP6 forces string types, then I'm pretty screwed. I've always used PHP so I didn't have to declare the type of variables.

[lastcraft]

Hi...

Somehow I thought that you had a similar sentiment in a previous thread regarding incremental breaks in the PHP5.0.x line some months back (?)

Did I? I have always prefered small releases in general, so I'd need more context.

Suppose they did this...
1) PHP 4.9 allows proper cloning and deprecates the copy symantics of $a = $b for objects in fvour of $a = $b->clone(). That would have been the only change, the $a = &$b would stay, even encouraged.
2) PHP5 changes the symantics to $a = $b is a reference copy making the '&' redundant. It's declared deprecated. PHP5 would run a little slower, because it would have to perform object type checks whilst both systems were supported. Alternately an ini setting at teh start of teh script declares one behaviour or another to maintain performance.
3) PHP5.1 declares the & for object copying a notice.

No other features are added to PHP until this migration path is complete. I am sure the whole process could have been comleted two years ago if this had been the only goal.

In other words, it's necessary to think two versions ahead so that there is always a valid intermediate state.

For really excellent examples of big release death: Netscape 5, Perl 6.

yours, Marcus

[Dr Livingston]

One big release for lots of breakage is far better than many small breaks.

I dropped PHP4.x development almost over night, and started afresh with PHP5 after a break; I took a lose of income for a month or so but when I look back I have no regrets now.

As for what Marcus is talking about, well I tend to treat his postings nowadays, with a pinch of salt. With small incremental refactorings you still achieve your goal I suppose, it just means it takes longer.

Far better to take the bull by the horns, so to speak, or not at all in my view. Welcome to 2006 btw everyone

[capiCrimm]

I like to think of php5 and 4 as meeting the ``two version'' requirement of bazzar development. For new projects I'd definetly have a look at php5, but it really depends on the project. If your just writing simple scripts or are trying to seel something, like other people have said it's best to stick with php4. OO really shows it's grace when you get to bigger projects, and that's where I'd start looking at 5.

For really excellent examples of big release death: Netscape 5, Perl 6.

I must be missing something here. I like the idea of constant releases(Bazaar model again), but I'm failing to see how the examples fit into what your talking about. From what I'm grasping Perl 6 and Netscape 5 are more like Duke Nukem Forever. I can sorta see where your coming from with Perl6. However, it seems a little to early to speak about something thats not even finished.

The projects your talking about seem to be ones that seem to take on too much that they won't get finished. I thought the discussion was about php5 breaking backwards compatibility?

[lastcraft]

Hi...

The projects your talking about seem to be ones that seem to take on too much that they won't get finished. I thought the discussion was about php5 breaking backwards compatibility?

There are separate points here...

The examples lost, or are in the process of losing, their user base. The bigger the upgrade, the more likely they are to jump ship altogether.

Taking a big upgrade in one go means that you have to absorb a large number of fixes in one go, a lot of which may be interdependent. When something breaks you have multiple culprits. You always want to go in small steps with software.

If you want to do a server upgrade to PHP5 (without downtime on multiple servers), you don't want to be changing your code base as well. I'd rather have a transitional code base that I could run side by side on the old servers. Again, I want to know that a failure is a PHP5 technical problem rather than accidents in the code as a result of technical changes.

yours, Marcus