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

Reply via email to