Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37641 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96062 invoked from network); 14 May 2008 00:07:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 May 2008 00:07:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Linux 2.6 Received: from [85.214.94.56] ([85.214.94.56:54251] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A4/A2-09150-B2D2A284 for ; Tue, 13 May 2008 20:07:09 -0400 Received: from MBOERGER-ZRH.corp.google.com (109-149.79-83.cust.bluewin.ch [83.79.149.109]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id 32FD611F00F; Wed, 14 May 2008 02:07:04 +0200 (CEST) Date: Wed, 14 May 2008 02:06:33 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1629174644.20080514020633@marcus-boerger.de> To: Christian Schneider , Stanislav Malyshev CC: Marcus Boerger , internals@lists.php.net In-Reply-To: <4829A0C9.5050308@cschneid.com> References: <48169695.9040803@omegavortex.net> <7dd2dc0b0804290817v3d8de030y1208a88f78c44411@mail.gmail.com> <862660524.20080506162159@marcus-boerger.de> <912CE6DE-22D0-43E6-BB6B-6154980050E5@procata.com> <1210101672.3952.4.camel@localhost> <489751132.20080506214551@marcus-boerger.de> <10845a340805070633q2316a598lc1a69f259c523341@mail.gmail.com> <92634160.20080512164700@marcus-boerger.de> <10845a340805120803k2587870bnf890ce44765f5e97@mail.gmail.com> <721653902.20080513155302@marcus-boerger.de> <4829A0C9.5050308@cschneid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Class Properties in Interfaces? From: helly@php.net (Marcus Boerger) Hello Christian, Stas, Tuesday, May 13, 2008, 4:08:09 PM, you wrote: > Marcus Boerger wrote: >>> unset($o_Foo->bar); >>> echo $o_Foo->bar; >> ?>> >> >>> outputs ... >>> Notice: Undefined property: foo::$bar in C:\- on line 13 >> >> At this point you found an error. Because this allows unset() to modify an >> instance in a way that it nolonger adheres to its class that means at this >> point the following is nolonger valid: $o_Foo is-a foo. And that is the >> basic design rule we chose for PHP. Please file as a bug! > So you are saying that > $o_Foo->bar = array(42); > is ok when the class "expects" a string but > unset($o_Foo->bar); > or (as as slight variation) > $o->Foo->bar = null; > is not? I Do not get the connection here? And since when can we 'expect' a string only for a property? My point is that an object should always have a property, whether it has the value NULL or not doesn't matter at all. And actually unsetting a property right now doesn't change much besides that it breaks inhereitance rules and affects reflection (maybe, not tested). Becasue when a defined property is unset() and that infact results in deletion than the property information ist still present in the class. The next access to that property now must not result in an error (not even E_NOTICE as even that would be misleading, people would try to find the error in the class). And anyway PHP happily recreates the property with value NULL if being accessed. And if the property is not declared than PHP will simply create a new property on access. This creation of undeclared properties does not affect any inheritance rules and was decided on. This is what Sats meant with what PHP allows beyond C++ and Java. Allowing anythign more breaks our basic design principles. > I'd ask not to change this behaviour as you'll just add another (IMHO > bogus) restriction on how an object or class can be modified at runtime. > An error possibly caused by this is already handled by the E_NOTICE > message anyway. > For comparison: Having to declare static class variables is a similar > restriction which got in my way more often than it helped me. > - Chris Best regards, Marcus