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