Hi! > E_CAST is problematic. Having something we encourage some people to > make an error and some people not to means that in some cases your > library works fine and rosy in other people’s environments and > sometimes it crashes your app. This is *not good*. We must not > encourage people to make things errors conditionally. It’s either an > error or not. I’d veer towards error.
I think this is not correct. It can be OK in one context and error in another. I.e., if you say "let's ask users how many gizmos they want" and the user gives "1 " (note the space) and we tell them "we don't know what this even means, there's an extra character there" - doing this would just annoy the user. Silently converting it to 1 would do the right thing. If you say making any distinction between "1" and "1 " is useless for you - well, I can accept that. I can see use cases where it makes sense to make distinction but they are a minority. I think there's a level between E_RECOVERABLE_ERROR and silence where it's not "I can't make any sense out of this garbage" but also not "it's clean data". But I can also live without this level, if that is what the majority comes to. In that case, I'd rather have "1 " converted to 1 silently. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php