Re: PHP4 vs PHP5 Performance?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



i know this thread started off about a performance comparison, but it is
already grown into much more.
suffice it to say that i consider the oop capacity of php4 nothing more than
a stepping stone on the way
to php5.  i dont know of all the oop languages out there.  mostly i have
worked w/ c++ and java
(and a little .net and a tiny bit of delphi) when it comes to oop.
all of those languages have ppp; which i consider to be fundamental to an
oop language; but alas
php is not an oop language; it merely supporst features of an oop language.
 per statements on php.net.

then again javascript is supposedly oop, and i know it doesnt support ppp;
so we would really have to
dig deeper for a definition of 'basic oop' / 'true oop' etc.

from a personal standpoint i have been leraning how to leverage the power of
the interface construct
for 1.  on top of that, well i think no ppp is madness... but again, thats
nothing formal :)

-nathan

On 8/25/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:
>
> On Sat, 2007-08-25 at 11:09 -0500, Larry Garfield wrote:
> > On Saturday 25 August 2007, Robert Cummings wrote:
> >
> > > Rewriting? You're assuming developers of PHP4 are using all of the
> > > features in PHP5 but written using PHP4 code. That's not a very valid
> > > assumption. You're also assuming they didn't already have code written
> > > in PHP4 that was then duplicated b internal code in PHP5. Hell, many
> > > PHP4 AND PHP5 developers don't even use OOP. Tell me what is
> compelling
> > > in PHP5 that doesn't rely on you being an OOP developer? Exceptions
> > > don't count since that's an individual bent. C has no exceptions and
> it
> > > gets on fine (PHP is written in it :)
> > >
> > > Cheers,
> > > Rob.
> >
> > There is no way to respond to the above request, because you're
> automatically
> > discounting features as "an individual bent".  That makes your position
> > non-falsifiable (cannot be proven or disproven), and therefore
> irrelevant.
>
> I'm indicating that features should not be the sole basis of the
> argument since they are indeed an individual bent. As such it helps to
> focus the argument to what is important-- the efficacy of PHP4 versus
> the efficacy of PHP5. Thus my position is open to falsifiability and not
> as you say "irrelevant".
>
> > What does PHP 5 offer?
> >
> > - Exceptions.  No you don't have to use them, but they are a useful
> tool.
> >
> > - Real OOP.  No, you don't have to use it, but it is a useful tool.
>
> Ooooooooooooooh, the magical "Real OOP". Please go find me a definition
> of "Real OOP". PHP4 is as real OOP as any other OOP. Just because it
> lacks some devices available in other OOP implementation does not
> disqualify it in any way from being OOP.
>
> > - Prepared statements in MySQL (mysqli) or cross-database (PDO).  You
> really
> > should be using them!
>
> There are pros and cons to prepared statements:
>
>     "Sometimes prepared statements can actually be slower than regular
> queries. The reason for this is that there are two round-trips to the
> server, which can slow down simple queries that are only executed a
> single time. In cases like that, one has to decide if it is worth
> trading off the performance impact of this extra round-trip in order to
> gain the security benefits of using prepared statements."
>
> Any conscious developer can properly escape their queries to be secure.
> While PDO offers access to features that are not common to all DBs it
> does so in a non-portable way as would be expected. As such it's just
> another database abstraction layer. It's quite simple to write wrap this
> in a pre-existing PHP encoded database abstraction layer.
>
> > - filter extension.  No you don't have to use it, but it's a useful tool
> for
> > security.
>
> Sure, but you can filter your variables for security without it.
>
> > - SPL.  You can leverage SPL without having a fully-OOP
> architecture.  In
> > fact, I find it most useful to be able to "have my procedural cake and
> OOP
> > icing, too".  No, you don't have to use it, but it's a useful tool.
>
> But it doesn't offer much to a fully procedural architecture.
>
> > - SimpleXML and the DOM extension.  XML handling that doesn't suck
> ass.  No
> > you don't have to use them, but if you're doing anything with XML
> processing
> > you will thank the gods that you did.
>
> I already have an XML API that works fine in PHP4.
>
> > - A few dozen new utility functions.  Sure they could be/have been
> > reimplemented in PHP 4 user-space, but they're not as fast as when
> > implemented in C.
>
> True, but that's a compatibility / performance tradeoff. And there
> doesn't need to be a tradeoff. You can test for PHP4 and include the PHP
> versions if PHP4 is active. Otherwise default to PHP5 C implementations.
>
> > That's just off the top of my head.  PHP 5 offers a ton of extra tools
> that
> > can be useful in many situations.
>
> Sure it offers a ton of extra tools, but there may be a ton of libraries
> abandoned that haven't been made compatible with PHP5. Although I must
> admit it's quite easy to make code PHP5 compatible.
>
> > If you're on a PHP 4 server, you have no choice but to not use them.
> >
> > If you're on a PHP 5 server, you can pick and choose which to use based
> on
> > your use case and preferences.
> >
> > The GoPHP5 project is not about forcing people to use OOP.  It's about
> > ensuring that developers have a full tool box available to them when
> writing
> > code.  If you're still using PHP 4 now, then your tool box is only
> half-full.
> > Get on PHP 5 to get the other half.
>
> I never said gophp5 was about forcing the use of OOP. It just strikes me
> as an unnecessary push when market forces will perform the appropriate
> pushing at the appropriate time. GOPHP5 is an artifical push for a
> faster move towards an inevitable future.
>
> > The other factor is that those writing code that goes on servers they
> don't
> > have absolute control over (I dare say most of us) are bound by
> *others'*
> > refusal to upgrade to PHP 5.  If I'm on a shared host, I'm stuck with
> > whatever that host is running, even if it's ancient.
>
> I've nothing against running your stuff in PHP5, nothing against it at
> all. But I don't see what the problem is with maintaining PHP4
> compatibility while enjoying PHP5 if you so choose to use PHP5.
>
> > Supporting PHP 4 hurts PHP 5 developers.  Supporting PHP 5 does not hurt
> PHP 4
> > developers.  That's the problem.
>
> Actually it means PHP4 developers must ensure their apps are PHP5
> compatible. This may or may not involve a chuck of legwork. Legwork
> involves time, time involves the bottom line. The bottom line can hurt.
>
> > For more info:
> >
> > http://gophp5.org/faq
>
> *waves a tiny "gophp5" flag* Yaaaaaaaay!
>
> Cheers,
> Rob.
> --
> ...........................................................
> SwarmBuy.com - http://www.swarmbuy.com
>
>     Leveraging the buying power of the masses!
> ...........................................................
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux