Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.96 cause and error)
To: internals@lists.php.net
Date: Wed, 28 Jul 2010 01:11:59 -0500
User-Agent: KMail/1.12.2 (Linux/2.6.31-22-generic; KDE/4.3.2; x86_64; ; )
References: <AANLkTik4W01g4JNK21jww57z-qXZDudr4pDRMtayn6Lt@mail.gmail.com> <4C4C1839.2060307@thelounge.net>
In-Reply-To: <4C4C1839.2060307@thelounge.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-ID: <201007280111.59974.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Please reconsider supporting PHP 5.2
From: larry@garfieldtech.com (Larry Garfield)

On Sunday 25 July 2010 05:55:53 am Reindl Harald wrote:

> A clean designed application has to run the whole time with
> error_reporting = E_ALL | E_STRICT and so you should have seen
> the problems long ago
> 
> > This broke Drupal 6 big time and while core has been fixed, contrib is
> > a bit slower to adapt. Previously, it was possible to pass in simply
> > NULL if you did not care about the by-reference argument.
> 
> The problem is that the developers of drupal, joomla, wordpress
> are not working error_reporting = E_ALL | E_STRICT as i do since
> teh first day i use php even on production servers

One catch here is that E_STRICT implies no PHP 4 compatibility, as E_STRICT 
chokes on PHP 4-style class usage, etc.  Drupal 6 had PHP 4 compatibility so 
E_STRICT was not an option.  The core system was developed to E_ALL standards, 
but not all add-on modules (which are the lifeblood of any modular framework) 
are.  I cannot speak for other projects but since Joomla, Wordpress, and 
CakePHP all were PHP 4-friendly until their most recent versions at least I 
suspect the story is much the same.

I'm not disagreeing with you about writing pedantically correct code from the 
get-go (I've been a strong advocate of that in Drupal for quite some time), 
but when you have a code base that goes back nearly a decade and need to not 
lock out casual module developers who don't understand the intricacies of 
error level configuration and don't have root on their servers it's 
(unfortunately) not as simple a question as you make it out to be.

That said, I'm actually against the removal of $foo(), not for BC reasons but 
because call_user_func() is *not* a viable replacement (it's actually 
considerably slower), $foo() is much easier to read (IMO), and because I've 
never once been confused by ::$ that I can recall.  

--Larry Garfield