Hi! > So nobody should ever use libraries, because they can't be sure of that > code... So...
Libraries have classes and interfaces for exactly this reason - so you can be reasonably sure what's in them or at least have easy way to check it. > It's checking that fatal method-not-defined erros won't be thrown... But instead a fatal "protocol does not match" error will be thrown. The difference? > It gives the ability for a method to be defensive by preventing E_FATAL > errors. That's not adding something significant? I fail to see the difference between one error and another error. The whole "catchable" thing is very artificial difference and as far as I'm concerned, if that's the problem, just make method-not-defined "catchable", whatever that might mean - there's no difference on the substance that I can see. > I agree the use-cases are slightly weak. This is a draft RFC. It's > supposed to help identify the areas where we can improve it. Help > identify use-cases. Help dig it out. My personal opinion regarding design always was that use cases come first. If I don't have a use case, there's nothing to design. So I'd like to see the convincing use case first. Then, once it's convincing, we can talk about implementation details - so yes, you can discard all the performance, etc. talk - it's not important right now, the most important thing is the use cases. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
