On Wed, Sep 24, 2008 at 10:40 PM, Tim Starling <tstarling(a)wikimedia.org> wrote: Why not just raise a user warning if an invalid string parameter is passed?

On Thu, Sep 25, 2008 at 6:36 PM, Roan Kattouw <roan.kattouw(a)home.nl> wrote: Mistyping a constant isn't a syntax error in PHP. It's a runtime error. This completes with no errors: php -r "class A {} if( false ) echo A::foo;" This gives a fatal error: php -r "class A {} if( true ) echo A::foo;" In other words, the constant only gives an error when it's actually evaluated. Which is exactly the same as happens if you pass to a function that raises a warning when a bad constant gets passed to it, except that the error occurs marginally later (when the function begins executing instead of immediately before it's called).

On Fri, Sep 26, 2008 at 1:10 PM, Brion Vibber <brion(a)wikimedia.org> wrote: Which is why the alternative we were discussing was having the functions validate their own input and raise a warning or error if passed bad input. That also provides runtime failure, which would be at least as descriptive. More descriptive if we threw an exception, since it would give a stack trace -- although less descriptive if it just raised a warning, unless the warning said what line of code the caller was on. Is it possible to figure out the caller without parsing debug_backtrace() or something similarly horrible?

On Fri, Sep 26, 2008 at 4:12 PM, Roan Kattouw <roan.kattouw(a)home.nl> wrote: Yes, which makes the strings slightly more complex in that regard. But to recap their benefits: * Human-readable in stack traces and other sorts of dumps. * Shorter due to no possibility of namespace conflicts. * More human-readable in source code (no all-caps or incomprehensible prefixes). * Can be used in LocalSettings.php and other places before AutoLoader is executed, unlike class constants (you need to use global constants, which suck even more than class constants). * No confusion about how to combine them. (How many times have you seen someone say to set error_reporting( E_ALL & E_STRICT )? I've seen it more than once.) * Easier extensibility: extensions don't have to worry about conflicting with core code when defining new parameters, unlike with parameters that are secretly numeric. * Probably others that I'm not thinking of this second, where was my last post on this? I can't find the thread.