On Thu, 3 Aug 2006, Rasmus Lerdorf wrote: > Pierre wrote: > > > > On 8/3/06, Derick Rethans <[EMAIL PROTECTED]> wrote: > > > > > > In this particular case I think it should be possible to mark > > > certain internal > > > > methods as strict and keep userspace methods loose. > > > > > > But I would like to see atleast an e_strict warning of signatures are > > > violated to give atleast the options to be strict and get warnings for > > > it. I am pretty sure Edin doesn't give a **** about e_strict warnings... > > > so that will work fine. I think that Zeev suggested something like this. > > > > For what I understand (and agree), he meant the other way 'round. > > Users who like strictness will have to use an extra keyword in the > > declaration. Users who don't care will not have to change anything in > > their (working) code. > > I'm not all that keen on a new keyword for this. How about using an interface > to indicate strictness? Isn't this really what interfaces are all about?
There is however a problem with this approach: You would still need to modify code in order to get things "strict". Take for example some code that I have running (and want to keep running) on PHP 5.1. If in 5.2 we suddendly need to implement a specific interface in order to get strict behavior this code will no longer run on PHP 5.1 (without hacks). The other option is not to mark things as strict but that can makes things a bitch to debug. However, if we follow Zeev's proposal then there are no real problems at all - technical wise. Only having to ignore E_STRICT in case your apps are violating some core OO rules is then necessary. Splitting out E_STRICT into different error levels might work as well, but I am not so sure if that is necessary. So let me sum up the things from Zeev's proposal) and dropping his 4th point from it. - Add a new flag to methods (at the implementation level) that will allow to flag them as 'strict' - In case such a strict method is improperly overridden - error out (E_ERROR) - In case a non-strict method is improperly overridden - emit E_STRICT I think this is perfectly acceptable as it address both the people who want strictess, without having to change any code, and the people who do not care about it, which can simply ignore E_STRICT then. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
