On Wed, Sep 24, 2008 at 5:44 AM, tstarling@svn.wikimedia.org wrote:
Revision: 41222 Author: tstarling Date: 2008-09-24 09:44:45 +0000 (Wed, 24 Sep 2008)
Log Message:
Fixes for r41154 and r41155:
- Boolean parameters are widely accepted to reduce readability. Replaced the new boolean parameters with class constant parameters instead.
I thought you said you preferred literal strings to class constants.
Aryeh Gregor wrote:
On Wed, Sep 24, 2008 at 5:44 AM, tstarling@svn.wikimedia.org wrote:
Revision: 41222 Author: tstarling Date: 2008-09-24 09:44:45 +0000 (Wed, 24 Sep 2008)
Log Message: ----------- Fixes for r41154 and r41155: * Boolean parameters are widely accepted to reduce readability. Replaced the new boolean parameters with class constant parameters instead.
I thought you said you preferred literal strings to class constants.
In some cases, yes. I think literal strings are especially useful when there's a lot of options, and they're defined at runtime, such as with magic words or user rights.
Defending the API, Yurik argued that class constants provide a useful level of parameter validation, which I think is a reasonable argument in some cases. They also fit in with the existing practice in Revision.php (the DELETED_* constants).
-- Tim Starling
On Wed, Sep 24, 2008 at 10:40 PM, Tim Starling tstarling@wikimedia.org wrote:
Defending the API, Yurik argued that class constants provide a useful level of parameter validation, which I think is a reasonable argument in some cases.
Why not just raise a user warning if an invalid string parameter is passed?
Aryeh Gregor schreef:
On Wed, Sep 24, 2008 at 10:40 PM, Tim Starling tstarling@wikimedia.org wrote:
Defending the API, Yurik argued that class constants provide a useful level of parameter validation, which I think is a reasonable argument in some cases.
Why not just raise a user warning if an invalid string parameter is passed?
I think he means that typos in those constants are noticed better, because mistyping a constant constitutes a syntax error while mistyping a string doesn't.
Roan Kattouw (Catrope)
On Thu, Sep 25, 2008 at 6:36 PM, Roan Kattouw roan.kattouw@home.nl wrote:
I think he means that typos in those constants are noticed better, because mistyping a constant constitutes a syntax error while mistyping a string doesn't.
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).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aryeh Gregor wrote:
On Thu, Sep 25, 2008 at 6:36 PM, Roan Kattouw roan.kattouw@home.nl wrote:
I think he means that typos in those constants are noticed better, because mistyping a constant constitutes a syntax error while mistyping a string doesn't.
Mistyping a constant isn't a syntax error in PHP. It's a runtime error.
A runtime error still gives you more useful information while developing and debugging than silently passing through a string which, at some unspecified future time, doesn't do what you expected.
- -- brion
On Fri, Sep 26, 2008 at 1:10 PM, Brion Vibber brion@wikimedia.org wrote:
A runtime error still gives you more useful information while developing and debugging than silently passing through a string which, at some unspecified future time, doesn't do what you expected.
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?
Aryeh Gregor schreef:
On Fri, Sep 26, 2008 at 1:10 PM, Brion Vibber brion@wikimedia.org wrote:
A runtime error still gives you more useful information while developing and debugging than silently passing through a string which, at some unspecified future time, doesn't do what you expected.
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?
If constants are passed as function arguments as they usually are, the warning would occur on the calling line, not in the function itself, so you immediately know who the caller is.
Roan Kattouw (Catrope)
On Fri, Sep 26, 2008 at 4:12 PM, Roan Kattouw roan.kattouw@home.nl wrote:
If constants are passed as function arguments as they usually are, the warning would occur on the calling line, not in the function itself, so you immediately know who the caller is.
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.
wikitech-l@lists.wikimedia.org