Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26199 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46214 invoked by uid 1010); 23 Oct 2006 19:34:33 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 46199 invoked from network); 23 Oct 2006 19:34:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Oct 2006 19:34:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain php.net from 82.94.239.5 cause and error) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.94.239.5 jdi.jdi-ict.nl Linux 2.5 (sometimes 2.4) (4) Received: from [82.94.239.5] ([82.94.239.5:57171] helo=jdi.jdi-ict.nl) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AA/10-39788-6491D354 for ; Mon, 23 Oct 2006 15:34:31 -0400 Received: from localhost (localhost [127.0.0.1]) by jdi.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id k9NJYRuf026923; Mon, 23 Oct 2006 21:34:27 +0200 Date: Mon, 23 Oct 2006 21:33:39 +0200 (CEST) X-X-Sender: derick@localhost To: Marcus Boerger cc: PHP Developers Mailing List In-Reply-To: <1485570655.20061023210857@marcus-boerger.de> Message-ID: References: <1485570655.20061023210857@marcus-boerger.de> X-Face: "L'&?Ah3MYF@FB4hU'XhNhLB]222(Lbr2Y@F:GE[OO;"F5p>qtFBl|yVVA&D{A(g3[C}mG:199P+5C'v.M/u@Z\![0b:Mv.[l6[uWl' MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] [RFC] E_DEPRECATED From: derick@php.net (Derick Rethans) On Mon, 23 Oct 2006, Marcus Boerger wrote: > after recent discussions (over the last three months)I finally made up my > mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea > proposal is to do the following: > > - Add a new severity E_DEPRECATED +1 > - severities are used as follows: > . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst > removal would be two minor versions or one major version later. That is > something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0. > However both marking it as deprecated as well as removing it would > require a consensus on the list. +1 > . E_STRICT any rule that reflects common strict standards, like OOP theory > that is considered harmless if not followed. For example the combination > 'abstract static' makes no sense in said theory but doesn't put our zend > engine in an unstable state. +1, but then we should also expand this to include: - setting object variables without declaring them - auto-creating objects of stdclass on the fly - and other things that you *should* (not) do These can be added later ofcourse, doesn't have to be directly in 5.2.0, however that would probably be better. > . E_NOTICE or E_WARNING are used for input validations (e.g. domain errors). +1, but I think we need to specify when exactly to use E_NOTICE, E_WARNING, E_RECOVERABLE_ERROR and E_ERROR as well. > - We drop the current standard INI files and provide two new, namely > . php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED) > . php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING)) > . E_ALL does not contain E_STRICT or E_DEPRECATED -1, We should include E_DEPRECATED in E_ALL. > - We delay 5.2.0 and revisit all errors and change them according to the > new model. We also put any change into the upgrading file. +1 regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org