I think this is all going way too far. If one wants a "loose" class, you'll just have to suppress errors? That just doesn't sound right. It's like having a feature, but the system telling you "don't use it! it's bad!".
If anything, I think E_NOTICE would be much better than E_STRICT, which only seems to be an option because the not-loose classes are called "strict" classes. Still, I think triggering errors/notices/whatevers just sounds wrong. People want to code clean with all messages visible, And want to use (or not use) this loose feature that's being discussed. I would never dream of using a feature that triggers error messages, and so the feature isn't viable for me (and a lot of other people). - Ron "Jochem Maas" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > 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
