|
|
Posted by Robert Cummings on 08/14/05 21:38
On Sun, 2005-08-14 at 13:52, Matthew Weier O'Phinney wrote:
> * Robert Cummings <robert@interjinn.com> :
> > > Please tell the list why -- what does PHP4 offer over PHP5 for you? I
> > > honestly want to know, and I'm sure there are others who would be
> > > interested to see why people are not making the switch.
> >
> > While I've dabbled with PHP5 and made my framework compatible with it I
> > haven't bothered to make a wholehearted leap into it. The following
> > reasons basicly sum up why, and are probably common amongst those that
> > aren't leaping into PHP5.
> >
> > - Better the devil you know than the devil you don't. Many PHP
> > developers have spent years using PHP4 and know it inside and
> > out and have come to terms with all of it's deficiencies... as
> > few as those may be once you learn how to adapt to them.
>
> This is a fear-based argument. Arguments like this prevent innovation.
> Yes, I know PHP4's deficiencies and quirks inside and out -- but that
> doesn't mean I should stick with them. If I were to use that argument, I
> would never have left perl for PHP.
This may be a fear based argument, but it's also a perfectly adequate
and common argument. While there's some degree of fear, moving into the
realm of knowing PHP5 inside and out like many of us know PHP4 will
require much of our time and resources, that perhaps many of us do not
feel like investing right now. Undoubtedly as you have left perl for PHP
there will come a time when the benefits of PHP5 or PHP6, or whatever,
will seem compelling enough for many to make the leap. But just because
it's a new version does not in any way dictate to us that we MUST make
the leap now, just as when PHP4 first came out I doubt greatly you said
to yourself "holy crap PHP4, I must dump Perl immediately". In contrast
when PHP4 came out, PHP3 sucked sufficiently for many of us to make the
leap as fast as possible to take advantage of the better engine.
> PHP5 actually *fixes* many of PHP4's deficiences and quirks -- such as
> how objects are passed, how errors are handled, etc. I jumped onto PHP5
> because I wanted a PHP that worked *better*.
A PHP that works "better" is quite subjective. Sure PHP5 works better in
some areas, especially how objects are handled, but if I run script A
under PHP4 and I run it under PHP5 and there's no difference, then who
cares?
> > - A multitude of code already exists that is known to work under
> > PHP4 but can be expected to have quirks when run under PHP5.
>
> Explain. My experience, while limited, has shown that well-written PHP4
> code generally works quite well under PHP5.
Yes, well written code generally works quite well under PHP5, whether my
framework was written well or not is not for me to say, but I can attest
to having only had to change very few lines of code to make it work.
That said, I did have to change lines of code, and from what I recall
they weren't erroneous lines of code, just things PHP5 decided it didn't
like. Although admittedly I had to change some lines of code for PHP
4.4.0 also :)
> > - Much of the code written in PHP4 works without the new features
> > of PHP5 and so there's no compelling reason to invest time and
> > resources for 0 ROI other than compatibility with PHP5.
>
> Except that if you stay on an old version of PHP4, someday it will be
> deprecated and you'll *have* to upgrade. I, for one, would rather take
> smaller steps over time between versions than need to scrap an entire
> project and rewrite it from the ground up when the version reaches
> end-of-life. The ROI may be zero or small now, but priceless later.
Allow me to point to Apache 1 versus Apache 2. I don't see a mass
migration to Apache 2. In fact I bet you're probably still using Apache
1. At any rate, as I've said I updated my framework, I'm not arguing
against the utility of upgrading, only that many programmers of legacy
code, especially crappy legacy code, aren't going to feel compelled to
upgrade. Also I'm sure there's plenty of code out there used by lots of
people, but no longer maintained.
> > - PHP5 had a large focus on bringing missing OOP features to PHP
> > that have little merit to those who write mostly procedural code.
>
> The OOP rewrite was only a portion of the changes brought into PHP5.
> What about exceptions, or the mysqli support, or the simplexml addition,
> or...? There's a lot of stuff in PHP5 that procedural programmers can
> utilize.
I'll be honest here... I could care less about exceptions, mysqli
support or simplexml support. Everything in PHP4 was adequate for my
needs and needs I see in the future. These features are nice to have,
and I do make comments on the internals list for new features often
enough (in the hopes that in the future when I finally do make the
wholehearted move to PHP5 or even PHP6 only compatibility the features
are already there), but they aren't compelling enough to make me make a
break from PHP 4 compatibility just yet. And while I'm maintaining PHP4
compatibility, I'd rather just develop using PHP4 knowing that it will
pretty much work in PHP5 rather than develop in PHP5 and question
whether I might have introduced some PHP5 only feature.
> > - Accelerators for PHP5 are not particularly good at this time, so
> > unless you've got cash to shell out to Zend (which can be
> > expensive for the little guy) then why move from your trusty
> > PHP4 accelerators that already get the job done satisfactorily.
>
> As Rasmus noted under separate cover, the APC project has made
> tremendous headway in the past few months, and is working fairly well
> with PHP5 at this time.
Fairly well doesn't make me feel comfortable. If someone said the brakes
on this car work "fairly well" I sure as hell wouldn't buy the car.
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. |
`------------------------------------------------------------'
Navigation:
[Reply to this message]
|