Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Re: [MediaWiki-CVS] SVN: [36018] trunk/extensions/TorBlock

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


Simetrical+wikilist at gmail

Jun 8, 2008, 10:57 AM

Post #1 of 3 (260 views)
Permalink
Re: [MediaWiki-CVS] SVN: [36018] trunk/extensions/TorBlock

On Sun, Jun 8, 2008 at 6:48 AM, <werdna[at]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.)

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tstarling at wikimedia

Jun 8, 2008, 7:50 PM

Post #2 of 3 (233 views)
Permalink
Re: [MediaWiki-CVS] SVN: [36018] trunk/extensions/TorBlock [In reply to]

Simetrical wrote:
> On Sun, Jun 8, 2008 at 6:48 AM, <werdna[at]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


_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Simetrical+wikilist at gmail

Jun 11, 2008, 2:09 PM

Post #3 of 3 (218 views)
Permalink
Re: [MediaWiki-CVS] SVN: [36018] trunk/extensions/TorBlock [In reply to]

On Sun, Jun 8, 2008 at 10:50 PM, Tim Starling <tstarling[at]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 mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.