2008/5/19 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Hi!
>
>> Would the following be acceptable?
>>
>> (Not E_STRICT) If error_reporting does not include E_STRICT, then
>
> I think making the language internals depend on error_reporting setting is
> not a very good idea, especially on E_STRICT. I.e., I have nothing against
> making unset() trigger E_STRICT if it is warranted, though I'm not sure how
> exactly you'd implement that. But changing what unset() does to symbol table
> depending on E_STRICT is IMHO wrong. Error reporting is for reporting errors
> to the user, not switching engine to different incompatible behavior.
> Imagine WTF factor if same method call would act differently with and
> without @.
Ok. And I see what I said was wrong.
Maybe the solution is simply to throw an E_STRICT when unset()-ting an
interface property? My understanding is E_STRICT is to push the
userland dev into a certain direction (like this error from : Strict
Standards: Declaration of Derived::return_by_ref() should be
compatible with that of Base::return_by_ref()). You are allowed to do
the action, but it is going against "strict" rules to do so.
What I'm trying to determine is this.
Assuming unset() doesn't change in behaviour ...
1 - What are the benefits of having properties in interfaces?
2 - How are they any different to normal class properties?
>
>> interface foo {
>> public bar read fReadBar, write fWriteBar;
>> }
>
> You really don't want to make read and write keywords ;)
I did say ignore my syntax. I don't know what the syntax is going to
be, so I used something obvious.
--
-----
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
