Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37722
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Mon, 19 May 2008 16:07:20 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1988581588.20080519160720@marcus-boerger.de>
To: Stanislav Malyshev <stas@zend.com>
CC: Marcus Boerger <helly@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <4830C61A.6020003@zend.com>
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> <4830C61A.6020003@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Class Properties in Interfaces?
From: helly@php.net (Marcus Boerger)

Hello Stanislav,

Monday, May 19, 2008, 2:13:14 AM, you wrote:

> 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.

All right, which is why I didn't file a bug report or ask anyone to do it.
To me the thing is ok as reflection shows it anyway. The only thing I
don't like is making it possible to get a E_NOTICE on a well declared
property.

Best regards,
 Marcus