[01:08:01] 2 hours later [01:08:05] thank you TimStarling [01:09:17] this all makes a lot of sense. I'll start with cleaning up the overrides, supporting array of restrictions and making isEnabledByConfig [01:10:54] * TimStarling thumbs up [01:11:11] with isEnabledByConfig I wonder why is there a reason why we would even load a special page if we kinda know it's disabled? [01:13:10] mmm. ok, I see, never mind [01:15:44] I probably used a bit too much use of constructor parameters to configure SpecialPage, as opposed to overridable methods [01:16:19] I was influenced by some C++ code I was reading at the time which did that a lot [01:18:50] that was May 2004 -- very early in terms of my experience with PHP or architecture in general [01:22:15] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/3583 [01:22:35] you see displayRestrictionError() and userCanExecute() are already there in the initial commit [01:23:30] heh, I got back to the very beginning :) [01:57:52] Krinkle: what's needed for https://gerrit.wikimedia.org/r/c/mediawiki/core/+/692462 ? I want to rebase on top of that [01:59:51] AaronSchulz: what is this currently needed for? [14:41:46] Krinkle: to simplify the modtoken patch a bit [14:42:09] could go in either order though [15:06:02] AaronSchulz: how common is it to need the return value from increment ops? Maybe we could standardise/optimise on not returning it with an inefficient wrap by default for cases that really need it. Chatting with Tim a while back we could only find one or two in prod for non-memc. [15:06:17] Anyway, not for now, but curious what you think. [16:05:48] Krinkle: it's worth doing as another method or flag [16:06:30] might also be nice to require a key component for keys using incr* methods [16:06:41] that would avoid non-counter method interaction edge cases