Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:23506 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26377 invoked by uid 1010); 17 May 2006 06:10:18 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 26362 invoked from network); 17 May 2006 06:10:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 May 2006 06:10:18 -0000 X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.5 (sometimes 2.4) (4) Received: from ([204.11.219.139:37934] helo=lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id F6/37-19568-94EBA644 for ; Wed, 17 May 2006 02:10:18 -0400 Received: from [192.168.200.106] (c-24-6-5-134.hsd1.ca.comcast.net [24.6.5.134]) (authenticated bits=0) by lerdorf.com (8.13.6/8.13.6/Debian-1) with ESMTP id k4H6ADu7002987; Tue, 16 May 2006 23:10:14 -0700 Message-ID: <446ABE45.2040501@lerdorf.com> Date: Tue, 16 May 2006 23:10:13 -0700 User-Agent: Thunderbird 3.0a1 (Macintosh/20060414) MIME-Version: 1.0 To: Ilia Alshanetsky CC: PHP Internals List References: <6C67DAD9-B812-415A-BFD6-A4E963371551@prohost.org> In-Reply-To: <6C67DAD9-B812-415A-BFD6-A4E963371551@prohost.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Flamewar Summary From: rasmus@lerdorf.com (Rasmus Lerdorf) Ilia Alshanetsky wrote: > There are 2 PHP 5.2 changes there has been a lot of back and forth > flaming going around and we need to finally come to a decision about. > > The two topics are: > > Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL I don't like E_ALL & ~E_NOTICE suddenly starting to throw E_STRICT in a minor version upgrade. So I am -1 on that one as well. We agreed to do this in PHP 6 a while ago. What has changed to move that to 5.x now? > Addition of support for dynamic statics ala: class foo {} foo::$bar = 1; I don't really see why we need strictness here. If people want to redefine their statics on the fly, why get in their way? Of course, I also don't see why you would want to change the class definition on the fly like this. And would it change already instantiated objects of that class as well? So I am not against it assuming the semantics are sane. +0 I guess. -Rasmus