Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37718 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3412 invoked from network); 19 May 2008 11:47:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 May 2008 11:47:54 -0000 Authentication-Results: pb1.pair.com smtp.mail=cschneid@cschneid.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=cschneid@cschneid.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain cschneid.com from 195.141.85.117 cause and error) X-PHP-List-Original-Sender: cschneid@cschneid.com X-Host-Fingerprint: 195.141.85.117 uf1.search.ch Linux 2.6 Received: from [195.141.85.117] ([195.141.85.117:43090] helo=smtp.rim.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 06/F4-57662-7E861384 for ; Mon, 19 May 2008 07:47:52 -0400 Received: from localhost (localhost [127.0.0.1]) by rolig.search.ch (Postfix) with ESMTP id 9B43343393F; Mon, 19 May 2008 13:47:48 +0200 (CEST) Received: from smtp.rim.ch ([127.0.0.1]) by localhost (search.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05156-08; Mon, 19 May 2008 13:47:46 +0200 (CEST) Received: from [192.168.1.72] (ultrafilter-i [192.168.85.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rolig.search.ch (Postfix) with ESMTP id 356AF43390F; Mon, 19 May 2008 13:47:46 +0200 (CEST) Message-ID: <483168E1.7090004@cschneid.com> Date: Mon, 19 May 2008 13:47:45 +0200 User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: RQuadling@GoogleMail.com CC: PHP Developers Mailing List References: <48169695.9040803@omegavortex.net> <1629174644.20080514020633@marcus-boerger.de> <76FF1B4A-1CAB-407A-9E6D-41E8C1137FCB@cschneid.com> <1284376279.20080518132000@marcus-boerger.de> <203770284.20080518184111@marcus-boerger.de> <1082257838.20080518193053@marcus-boerger.de> <1351350.20080518223746@marcus-boerger.de> <4830C61A.6020003@zend.com> <10845a340805190155ha1f888bmf512862050bea02c@mail.gmail.com> In-Reply-To: <10845a340805190155ha1f888bmf512862050bea02c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at search.ch Subject: Re: [PHP-DEV] Class Properties in Interfaces? From: cschneid@cschneid.com (Christian Schneider) Richard Quadling wrote: > (Not E_STRICT) If error_reporting does not include E_STRICT, then > unset()'ting properties defined in interfaces is allowed and operates > exactly as it does on normal variables and for properties defined in > classes. Whilst this may break the contract, this is what currently > happens and for the sake of BC (until a better solution is found), we > leave things alone. Personally, I think the potential new feature of > properties defined in interfaces should not be allowed to be unset. > But I'm looking at what I want with this and I hope that the following > text allows it. > > (E_STRICT) If error_reporting does include E_STRICT, then unset()'ting > properties defined in interfaces is not allowed and triggers an > E_STRICT error. We don't need this distinction: If you unset a property and access it afterwards you get an E_NOTICE so it can already be detected. And introducing different semantics depending on E_*-modes opens up another can of worms a la ini settings: Writing an application compatible with all different modes becomes a PITA. I agree with Stas here: Theoretical OO purism (I yet have to be shown code misbehaving with the current implementation) should not lead to artificial restrictions and/or code changes with BC breaks. - Chris