Hi!
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body to
> reduce code, increase readability and enable IDE's to be even smarter.
I think while intent is good (avoiding repetitive code) the strict
implementation would do exactly the opposite of what should be done - it
would move the repeated validation from library code to client code.
WHich would negatively influence both readability (in case you do it
right) and code robustness (in case you forget to do the necessary checks).
the point is not flexibility, its finding a sensible common denominator
for validation of input parameters and optimizing the syntax for that case.
Why the point can't be flexibility?
And if we talk about common denominator, how many use cases must accept
1, but not '1' or '1.0'? How many use cases can accept float, but can't
accept integer? How many use cases need boolean but can't accept 0? How
many use cases need string, but should never accept object with working
toString() like SimpleXML element? I don't see many such cases now. Do you?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
