On Sun, Jun 8, 2008 at 6:48 AM, werdna@svn.wikimedia.org wrote:
+// Define new autopromote condition +define('APCOND_TOR', 'tor'); // Numbers won't work, we'll get collisions
Speaking of which, is there any reason for us to ever use named constants like APCOND_TOR rather than just strings? This isn't C, after all. I think it would be wise to deprecate such things for the future and just use strings, arrays of them if necessary, as with wfMsgExt() and similar. (Although in this particular case a named constant might be better, to be consistent with the already-established core conditions.)
Simetrical wrote:
On Sun, Jun 8, 2008 at 6:48 AM, werdna@svn.wikimedia.org wrote:
+// Define new autopromote condition +define('APCOND_TOR', 'tor'); // Numbers won't work, we'll get collisions
Speaking of which, is there any reason for us to ever use named constants like APCOND_TOR rather than just strings? This isn't C, after all. I think it would be wise to deprecate such things for the future and just use strings, arrays of them if necessary, as with wfMsgExt() and similar. (Although in this particular case a named constant might be better, to be consistent with the already-established core conditions.)
I had this argument with Yurik over constants in the web API. He said that constants provide validation because they'll throw a notice if you use one that's not defined. I'm not convinced, I think they're pointless, except when you want to make a bitfield.
-- Tim Starling
On Sun, Jun 8, 2008 at 10:50 PM, Tim Starling tstarling@wikimedia.org wrote:
I had this argument with Yurik over constants in the web API. He said that constants provide validation because they'll throw a notice if you use one that's not defined.
But:
1) They're longer, due to prefixing to avoid namespace collisions
2) They're harder to read, due to greater length, possibly cryptic prefixes, and the inevitable uppercasing.
3) They're prone to collisions if you actually use numerical values.
4) They're impossible to use if you prefix them correctly -- that is, as class constants rather than APCOND_ or GAID_ or similar gibberish -- and want to use them in, say, a config option, since AutoLoader.php isn't loaded at that point (is it?). And if it were, loading an entire class on every page load for the sake of some constants seems a little unnecessary. (Although, since it doesn't have to be parsed, does it really take any time to load class/function definitions with an opcode cache?)
If you want error-checking you can throw an error in your function if it's passed a bogus value.
I'm not convinced, I think they're pointless, except when you want to make a bitfield.
Why not just use an array, then?
wikitech-l@lists.wikimedia.org