Lukas Smith wrote: > Hi, > > well it seems that the initial vision of E_STRICT to denote future > deprecation is no longer valid. Then again it might have been a > misunderstanding from the beginning as E_DEPRECATED would have been the > more obvious name in that case.
I did try to point this out but I was probably ignored due to lack of karma (which is understandable given the volume of the thread). I don't care much about *real* strictness issues but I do develop with E_STRICT on because it tells me about things in my code that are depreciated and/or will be removed in future versions (which is something I do care about). so it seems an E_DEPRECIATED might be needed (requiring alot of E_STRICTS to be changed), or alternatively something like an E_NOTRECOMMENDED? someone just mentioned the the possibility of having this strictness (and maybe others?) error be thrown as an E_NOTICE. I personally like this approach because E_NOTICE does not have the same "this is second class code and the ability to run it will disappear in the future" connotations as E_STRICT does. kind regards, Jochem > > I still think that a flag on a per class basis would be the better > solution, but I guess I can accept this change. > > This reminds me again about my question of how E_STRICT warnings are > added and how things are then handled (E_STRICT becomes E_ERROR or the > feature is removed entirely) with the future releases. I think a clear, > written down policy is needed (and as always may be overwritten via > common sense on a case by case basis). > > regards, > Lukas > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
