2008/5/19 Stanislav Malyshev <[EMAIL PROTECTED]>:
> 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
>
>
Would the following be acceptable?
(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.
I think this would cover everything mentioned so far.
(Not E_STRICT) If you are used to being free-and-easy with your
variables/properties (not a bad thing if you know what you are doing),
then probably E_STRICT is of little use.
(E_STRICT) If you are more of a purist then you probably don't unset()
class properties and really wouldn't want to unset interface
properties. E_STRICT, in this instance, enforces that idea.
(Not E_STRICT) If you want to override the behaviour of unset() and
isset() for an interface property, then you can using whatever syntax
will be agreed for the definition
interface foo {
public bar read fReadBar, write fWriteBar, unset fUnsetBar, isset fIssetBar;
}
(maybe).
(E_STRICT) If we are enforcing the inability to use unset(), then
isset() has no bearing as the result can only ever be true. So if you
are using E_STRICT, should parsing an interface with unset and isset
defined also produce an E_STRICT error?
interface foo {
public bar read fReadBar, write fWriteBar;
}
would work (ignoring syntax please), whereas the previous interface
definition could produce the E_STRICT.
Richard.
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
