On Sat, 2007-08-25 at 12:28 -0500, Larry Garfield wrote:
> Robert and everyone: PLEASE do not reply to list AND the sender, at least not 
> when I'm the sender.  I don't need double copies of every message in every 
> thread I participate in.  Thanks.

Sorry I've been hitting reply-all since I first used email in '93. I
have my doubts I can seriously change my habits now. I've done so this
one time just for you though :)


> On Saturday 25 August 2007, Robert Cummings wrote:


> Sure you can.  You could do it in C, too, and then you don't need PHP's 
> overhead.  The "you can accomplish it without this tool" argument carries no 
> weight since the whole point of the tool is "but I can accomplish it in far 
> less time with less code and fewer bugs with it".  
> 
> You can build a house using nothing but a hand saw, but a buzz saw makes it 
> oh 
> so much easier. :-)

PHP4 is the buzz saw. PHP5 is the buzz saw with some extras.

> > > - 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.
> 
> Have you tried it?

Yes I've tried procedural development. it's fun, can be a bit tedious
passing around arrays, but altogether not bad.

> > > - 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.
> 
> There's only a narrow sliver of use cases where I'd say PHP 4's primitive SAX 
> parser "works fine".  Perhaps you're only working in those, but if you're 
> doing anything more complex then the extra tools make life a hell of a lot 
> easier.

I have a wrapper around the parser. I access fields using a very simple
path string.

    $xml->getLiteral( '/response/products/[EMAIL PROTECTED]' );

    or

    $xml->focus( '/response/products/product' );
    $products = $xml->getIndexes();
    foreach( $products as $pi )
    {
        echo 'Status: '.$xml->getLiteral( "[EMAIL PROTECTED]" );
    }

It works very well on very complex XML.

> > > - 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.
> 
> You have to be careful how you structure the code, though.  Conditional 
> function definitions still get compiled even if they aren't "defined", so 
> there's no memory savings.

They don't get compiled if you conditionally include the files that have
them.

> > > 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.
> 
> GoPHP5 *is that market force*.  It's developers saying "OK, we're sick of PHP 
> 4, it's time for PHP 5, get with the program".  Hosts that don't keep up, 
> well, that's capitalism.  It's well past the "appropriate time".  

No, GoPHP5 is an external force attempting to sway the market. If you
were THE market force then PHP5 would already be the majority version
and GoPHP5 would be moot.

> And actually, what I've found from GoPHP5 is that the Nexen stats showing 20% 
> PHP 5 deployment on a good day are bunk.  There's no shortage of PHP 5 
> compatible hosts, including the big names.  We've been holding ourselves back 
> needlessly.
> 
> > > 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.
> 
> Because it is not possible to use SimpleXML or SPL or PDO etc. while 
> maintaining PHP 4 compatibility, unless you write two completely separate 
> implementations with a common facade.

But if you already have those implementations because you're coming from
PHP4, then who cares. If I already have a huge codebase that uses PHP4
XML semantics then why recode those to use SimpleXML or SPL or PDO when
they already work fine in PHP4? Sure, if I have time, money, or
resources I can go ahead and do the conversion for the sake of
converting or using the faster C implementation, but otherwise I'm doing
extra work for nothing when the current code works. I'm all for PHP5
compatibility, but I just don't see the point in dropping PHP4
compatibility when it already works.

> That's a complete waste of my time.  I 
> can't enjoy PHP 5's exceptions (if I am so inclined) without cutting off PHP 
> 4 servers.  While there were lots of PHP 4 servers, most mass-market projects 
> were too afraid of cutting off their own install base to do so.  Now, though, 
> they have enough "market force" in toto that it's not a big risk to open up 
> to PHP 5 features.  

GoPHP5 is more akin to a lobbying group. They are trying to appeal to
the mass market to sway it's current position. Again, I'll just
reiterate, PHP5 good to have compatibility in the near future,
completely wholeheartedly embracing PHP5 at the expense of PHP4 when you
already have PHP4 compatibility and installed base-- questionable IMHO.

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

Reply via email to