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
