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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
