Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37715
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <4830C61A.6020003@zend.com>
Date: Sun, 18 May 2008 17:13:14 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <48169695.9040803@omegavortex.net> <862660524.20080506162159@marcus-boerger.de> <912CE6DE-22D0-43E6-BB6B-6154980050E5@procata.com> <1210101672.3952.4.camel@localhost> <489751132.20080506214551@marcus-boerger.de> <CC6F77E6-FA3C-4CE9-A82D-D3686A4AA4BD@procata.com> <10845a340805070633q2316a598lc1a69f259c523341@mail.gmail.com> <92634160.20080512164700@marcus-boerger.de> <10845a340805120803k2587870bnf890ce44765f5e97@mail.gmail.com> <721653902.20080513155302@marcus-boerger.de> <4829A0C9.5050308@cschneid.com> <1629174644.20080514020633@marcus-boerger.de> <76FF1B4A-1CAB-407A-9E6D-41E8C1137FCB@cschneid.com> <1284376279.20080518132000@marcus-boerger.de> <D4F13063-1E18-42B8-9B20-2FC0A4E0487C@cschneid.com> <203770284.20080518184111@marcus-boerger.de> <C4F1299D-F4B0-4F7E-A790-E1A358F37F83@cschneid.com> <1082257838.20080518193053@marcus-boerger.de> < 48307D10.1070905@zend.com> <1351350.20080518223746@marcus-boerger.de>
In-Reply-To: <1351350.20080518223746@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
From: stas@zend.com (Stanislav Malyshev)

Hi!

> As much as I agree on the interface part, changing my sentence from
> containing 'interface' to 'protocol' makes it even a bug today. And that
> by the way was the purpose of my mail.

I think it is not right to call it a "bug", since it works exactly as it 
was intended and designed to work. It's not like somebody just missed a 
check here or forgot an if or something.

Now, I understand that you want to change it, and have a good reason for 
it. However, it should be understood that this change has consequences - 
unset() stops being the operator it was before - i.e. operator 
undefining the argument variable, removing it from the respective symbol 
table - and starts being operator that sometimes undefines variable and 
sometimes sets it to null. Which has more consequences - e.g., you can 
not know what would be the effect of unset unless you know the initial 
declaration of the class. It also means PHP has now two kinds of 
variables - unsettable and not unsettable, and there's no way for 
developer to know which one is which without inspecting the source code. 
Unless, of course, you want to prohibit unsetting object variables 
altogether. Which would be even bigger change, since not all object vars 
are API parts - most of them are not.

My opinion is that adding a bit of OO purism in this case does not 
justify changing the way one of the basic language constructs behaves in 
a way that may lead to unforeseen and unwanted consequences. I think 
there's a limit to which the language should restrict the developer, and 
basing on PHP history and build as it is today I would say changing the 
way how unset() works to restrict developers from potentially writing OO 
code which is not nice goes beyond what language like PHP should do.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com