[15:31:52] hi guys [15:33:24] which team or whatever in wmf deals with registration of domain names? [15:34:57] Esuba: operations, usually. What’s up? [15:44:54] i would like to know whether wmf can registrate wikimedia.ua and вікімедіа.укр for Wikimedia Ukraine. It would also be nice to have domain names like wikipedia.ua, (perhaps also wikiquote.ua and so on), вікіпедія.укр to be registered. we had the latter one last year but it would be nice if WMF pays for that. We already have an issue [15:44:54] that wikipedia.org.ua is owned by some guy we dont know (so thare's also an issue that WMF should take it from him somehow) [15:45:26] andrewbogott: [15:45:33] Esuba: Best way to ask that is probably to open a phabricator ticket and add the ‘Operations’ project. https://phabricator.wikimedia.org/ [15:45:58] Esuba: it sounds like a reasonable request, that’ll get it in front of folks who do that sort of thing [15:46:59] thought about phab. thanks for the tip about project, will try that way [15:47:57] there is a "domains" project I think [15:48:01] probably the right place along with ops [15:48:43] yeah, probably both [15:49:26] about taking wikipedia.org.ua from it's owner is there some legal or whatever project [15:50:04] domains will be noticed by legal [15:50:14] all domain management is technically their purview and we facilitate [15:52:47] ok, thanks guys [16:03:31] https://phabricator.wikimedia.org/T95433 if anyone reading the messages above is interested to follow [17:27:25] wmf_highlight: Tesing wht this looks like. [17:27:37] testing again, non-highlight [17:54:30] [17:54:30] Good morning folks, Welcome to the Metrics di [17:54:30] scussion channel :) I'll be your host/question answerer today in our inauguration of the new 5th floor metrics space [17:54:33] hmmm odd [17:54:36] appologies for the spam :) [17:59:02] JeanFred: :) [17:59:12] * JeanFred waves around [17:59:20] Oh, hey rfarrand :) [18:00:19] * guillom huggles JeanFred. [18:01:26] * jamesofur notes to the people in the audience that the only way to avoid the camera is the front row (the VERY front row) [18:01:46] Also, please be advised that this channel is currently on a big screen in the office and will remain so throughout the meeting [18:01:46] * guillom notes that this chanel appears on the right-side screen. [18:01:52] +n [18:01:53] yes, that too ;) [18:02:14] JeanFred: o/ [18:02:53] stream is not up yet, right? [18:03:03] correct [18:03:07] jamesofur: HI! Is there a possibility to get the link in order to participate in from Google Hangout? [18:03:30] jessicarobell: in order to join the hangout itself or are you ok with the youtube stream link? [18:03:47] I move that the IRC stream uses Solarized colors. [18:04:02] jamesofur: I am not presenting but might need to answer questions. [18:04:26] it's in your PMs [18:04:32] not sure how crowded it is already [18:04:57] * JeanFred hugs back guillom and \o Krinkle [18:04:58] Chip has given an intro and is about to press the start button [18:05:07] (just advising people how to use the new mic system) [18:06:10] The stream 'should' be live now, starting is Erik with welcomes [18:06:19] is this the meeting channel? [18:06:29] mutante: yes [18:06:50] * bd808 sees stream after reload [18:06:52] streamed live into the office on the big screens [18:07:03] Trippy! I can see everyone [18:07:08] confirmed working :) [18:07:22] (in fact streamed onto 2 different screens now ;) ) [18:07:47] And now on 0 :( [18:07:55] I have a feeling that will change during questions [18:08:02] It's edited like early MTV, nice work behind the cameras, y'all! [18:08:06] Makes sense [18:08:23] LOL "It's edited like early MTV" not sure what to think about that [18:08:27] Eloquence needs camera blocking cues :) [18:08:58] bd808: yes, like TED's red zone [18:09:04] cndiv: ^ Just that note for later, our tendency to walk around may be tough for the cameras [18:09:10] "No pacing outside the zone" [18:09:19] should be sets mode +bigscreen :) [18:09:42] cndiv knows [18:09:45] (FIRST EVER!) [18:12:06] Hey it's Chip. How's remote audio? It's perfect for me in testing and then iffy once all these laptops enter the room. [18:12:07] * awight hell yeah's [18:12:25] Looks great! :D [18:12:26] wmf_highlight: works well, the applause goes in and out, but that's minor [18:12:39] wmf_highlight: Audio is good for me [18:12:48] Ainali: Good. It's better than it once was :-) [18:13:03] wmf_highlight: it is great, chip! :) [18:14:44] Youtube channel is very blurry for me. [18:14:49] Oh wait. better now [18:16:52] Learning that following pacers with the camera is hard... [18:18:07] Slides are not available as usual ? It wuold be quite helpful. [18:18:13] For presenters, it might be good to not put text in the lower right corners where the avatoars from the other people in the hangout are. Perhaps make a "safe space" template? [18:18:30] clearly our next purchase will have to be steadicam [18:18:31] Ainali: Noted. [18:18:57] wmf_highlight: yeah, +1 to suggestions on slides not using the bottom 5th-ish [18:19:28] PS the concept of this account is so you can 'highlight' a comment to the whole room, on the screens. Not really working yet. [18:20:13] wmf_highlight: are you still using the hangout-on-air question/answer thing? [18:21:03] greg-g: I don't personally see the advantage. IRC webchat is super easy. [18:21:10] JohnFLewis: see topic [18:21:10] for public channels [18:21:19] mutante: already loaded it thanks [18:23:07] wmf_highlight: I think that is a great idea! [18:23:19] PS those stupid "HDMI" inputs are a known issue. [18:23:25] Shorter! [18:23:36] Boo [18:24:20] Threat of the deadline! [18:24:28] Cool, Freakonomics Wiki style [18:26:48] * awight cheers with abandon [18:27:17] No slides then ? :) A link to the gdocs would be nice :) [18:27:19] wmf_highlight: then we should probably turn it off because there are questions in there right now [18:27:40] greg-g: Do you have the ability to send them here? [18:27:50] let's see... [18:27:56] JeanFred, maybe jamesofur knows [18:27:58] greg-g: but yeah, I'll turn it off next time. [18:28:09] If we have it it's on meta, one sec [18:28:25] Communications mined the quotes from that survey and shared them on social media in December [18:28:44] wmf_highlight: just "asked a question" to tell them, maybe :) [18:28:56] greg-g: perfect [18:28:56] jamesofur: It’s not linked from the Meta page (that was my first stop too :) [18:29:10] Google Hangout On air title: "Wikimedia Metrics 4.8.2015". http://xkcd.com/1179/ ! [18:29:16] JeanFred: it looks like now for right now. I will try to figure out if we have them anywhere else and get them up there after if not [18:29:32] I was told qs go here [18:29:41] wmf_highlight: The camera angle from slightly above feel strange. I think I would prefer a camera in eye-level with the presenter if possible [18:29:45] Thanks jamesofur :) [18:30:02] wmf_highlight: From earlier: Large banner is the first banner that people see; isn't it reasonable to expect that there would be gains from a "first" small banner as well? I don't see equivalency in this graphic. [18:30:10] Ainali: Yeah, the idea was to keep it slightly out of reach of people backing into it or accidentally hitting it. [18:30:26] Ainali: It's about 7.5 feet off the ground. [18:30:27] wmf_highlight: From earlier: ...so they tested threatening adverts on Wikipedia and were surprised that their results went way up? [18:30:40] Resident: Questions should go to jamesofur [18:30:54] Resident: I'm assuming that's a question you'd like to ask during question time? [18:31:01] normally this nick will be silent [18:31:28] I was told to send qs to wmf_highlight on the Google interface [18:31:41] Alright, cool. [18:31:50] Resident: Oh, not quite. That (eventually) will highlight on the big screen here. [18:32:12] Resident: but we'll still have a person in the room fielding IRC questions. Today that's jamesofur [18:32:16] I'll leave the questions for the Q&A, but I want to write them down somewhere :) [18:32:23] * jamesofur nods [18:32:27] I have it down Resident [18:33:19] Great work! [18:33:54] Some people are reporting that they can't enter this channel. [18:33:55] I think it's important to remind the fundraising team that many members of the community were not estatic that ads were threatened in this year's fundraiser, even in testing, since it's never going to happen. [18:34:32] (also is it possible to remove the people on the corner of the window? it's hiding parts of the slides) [18:34:57] Resident: try command (ctrl) + or - [18:35:43] wmf_highlight: I believe it's in the video itself. [18:35:50] it is [18:36:14] bah [18:36:51] I love the last one "My bad." [18:37:19] Oh and +1 for Signpost call-out :) [18:38:07] Sharing info with the independent media is awesome. [18:38:12] Resident: I can certainly mention it, but I think they know (the advertising comment) [18:38:36] (I write for it though so I'm not impartial though) [18:39:14] jamesofur: I'm interested in hearing their response because I'm not aware of what their stance is. Have they made a statement on it before? [18:39:28] I'm not sure [18:39:33] (I can't remember), I'll write it down [18:40:11] Deskana: are they getting an error? [18:40:23] They say they join the channel and it says there are 0 people in it. [18:40:30] hmmm.... [18:40:46] That sounds like it's possible there is a server disconnected... not sure there is anything we can do about it :( [18:40:51] I don't have time to triage the issue with them, so feel free to ignore my report. :-) [18:41:34] jamesofur: Q: How is the data that has been shown int this presentation being shared to the community? Is it done in a way so that the community are able to help a running fundraiser or only in a historical context? [18:41:39] I don't know what I find more surprising, the tospy-turvy situation with views on desktop/mobile or the amount of uncertaincy in that graph [18:41:42] Resident: Not an official statement, but I think "ads were threatened" is a totally unfair characterisation. It's just pointing out that we don't get money from that source, and we do rely on donations [18:41:52] Ainali: noted [18:41:59] In fact the banner says "we'll never run ads" [18:43:09] I can't Signpost coverage of the fundraising survey: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-03-11/Special_report [18:43:54] the-wub: I am looking at this: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-03-18/Op-ed [18:44:06] Q: Have we thought of special fundraising when users come to Wikipedia through Google Knowledge/Siri/Cortana answers ? [18:45:10] spagewmf: noted [18:45:14] it's high time bots and spiders start donating [18:45:24] ori: partnerships? :) [18:45:36] Their owners can certainly donate [18:45:46] jamesofur: Are the slides publicly available? I'd like to see the mobile slide again [18:45:59] Resident: they will be, but I do not have a link at the moment [18:46:01] maybe spider operators. bot operators are already "donating" their time by maintaining the bots. [18:46:01] I didn't catch the wording :( [18:46:50] ori, jamesofur: enter the FR throttler [18:47:43] “hi, it looks like you visited this page 30K times in the last minute, how about your owner gives us their PayPal account?” [18:47:49] heh [18:48:10] DarTar: Tsk. BitCoin for API access, dug. [18:48:44] BuxNet [18:48:53] The new VP is all about that [18:49:22] Q: How do values factor in our banner choices? Are we prepared to follow the numbers regardless of where they point, or are there limits to how far we will allow ourselves to intrude upon user experience? If so, are those limits articulated anywhere? [18:49:32] ori: have a small list, but noted [18:49:32] jamesofur: Can you ask them to speak about the new advancement department restructuring? [18:49:40] Resident: same, on the list [18:49:53] jamesofur: thanks [18:50:17] Q: Are we open to shifting progressively toward an endowment to reduce our dependency on frequent fundraising? [18:50:30] TrevorParscal: Yes. [18:50:46] TrevorParscal: See the latest Board minutes. It hasn't advanced very far beyond that level yet AFAIK. [18:51:22] Remote folks: are you hearing the rare audio static from the mics? [18:51:39] wmf_highlight: Yes, a little. Not a major issue. [18:51:47] Aha! [18:51:48] wmf_highlight: No, I cannot notice any. [18:51:51] :-) [18:51:59] It would be interesting to learn about the pros and cons of an endowment, I suspect it's not a silver bullet [18:52:36] wmf_highlight: yes, also echo cancellation artifacts every so often [18:52:45] wmf_highlight: e.g. when people are clapping [18:53:09] Signpost link: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2015-03-11/Special_report [18:53:41] ori: Short answer from the tech perspective, it looks like FR steers the boat pretty hard away from the local minima, which would probably be a huge marquee of offensive words in pink letters. [18:55:14] Hence why the endowment option is floating, there's a lot of money in the WMF pot. [18:55:16] awight: I know. And I also know from my personal acquaintance with the FR team that it is staffed by highly conscientious folk. <3 [18:55:18] wmf_highlight: I love the format with the static mic/camera that staff can ask questions from. Awesome work! [18:55:40] +1 Ainali [18:56:45] Ainali: the space is really about remote people and our communities. Glad you like it. :-) [18:56:55] Anything else from here? [18:57:08] Almost perfect timing [18:57:24] thanks all :) [18:57:43] Thanks for joining folks, the log will be posted on Meta and the obviously the youtube link is archives as usual. [18:58:01] Let me whip out my plane ticket and hop on a jet liner :( [18:58:05] nicely done, thanks y'all [18:58:07] Resident: There is a fair amount of money in reserves (in line with what charities our size generally have) but an endowment would require a lot more [18:58:36] Great job, see ya next month! [18:58:59] wmf_highlight: This was the best experience listening in remotely by far. [18:59:00] love to see the group on th 5th floor [18:59:42] yeah great job wmf_highlight, the a/v was excellent [18:59:54] the-wub: The Foundation brings in more than it needs for day-to-day ops, and now that chapter org has been restructured there's less waste in that pot to boot. [19:00:15] Endowment's a good strategic direction to take since they're worried about year-to-year fundraising. [19:00:25] But I'm not on the board so what do I know? :-) [19:00:41] wmf_highlight: The camera that you move around, is it possible to pre-program it on certain positions? I was mostly thinking on when you panned to jamesofur reading from IRC [19:00:55] Ainali: He's already using presets, yes [19:01:16] Don't know if he has one for that position [19:01:56] RoanKattouw: Ah, I see. If not better set one :) [19:02:31] Resident: oh yeah, it certainly seems like a good option to me. Just wanted to point out that it would be a significant effort to create [21:00:26] #startmeeting RFC meeting [21:00:26] Meeting started Wed Apr 8 21:00:26 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:26] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:26] The meeting name has been set to 'rfc_meeting' [21:00:41] * DanielK_WMDE_ wibbles [21:00:45] #topic Clean up URLs | RFC meeting | WMF Metrics Meeting April 2015 Stream: https://www.youtube.com/watch?v=To4HLZSrp0Y | Questions/Moderator: Jamesofur | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:01:34] #link https://www.mediawiki.org/wiki/Requests_for_comment/Clean_up_URLs [21:02:48] I think the main question with this RFC is whether glob rules in robots.txt are sufficiently widely supported [21:03:25] because I don't see anything else that is stopping us from doing it [21:03:43] o/ [21:04:03] i vaguely remember issues with content sniffing... [21:04:23] but that was just for action=raw, right? [21:04:38] if some bot doesn't support it, what would be the risk? That it goes into edit/history pages, etc.? I think if it does not happen to important bots (like google) then it's not super-big-deal [21:04:38] why don't we use action paths like /history/Foo, /edit/Foo, etc? [21:04:58] yeah, just action=raw, and just IE<8 [21:05:15] Twitter, Bing and Google seem to have a lot of glob rules in their robots.txt [21:05:29] Not sure that is conclusive about bots obeying them [21:05:33] since IE 8 introduced the "nosniff" tag, I think in Content-Disposition [21:05:55] so I imagine occasional broken bot is not that horrible... [21:06:19] how about /action/history/Foo? that would be even prettier - or is the common prefix essential? [21:06:25] SMalyshev: yeah, and presumably there are a lot of bots that ignore robots.txt completely, and the world doesn't end [21:06:56] bot and humans browsing together... it will be anarchy :) [21:06:58] right. We also can block bad bots by name (and seeing from robots.txt we already do) [21:07:16] well, that's not maintained [21:07:16] https://www.mediawiki.org/wiki/Manual:$wgActionPaths [21:09:42] DanielK_WMDE_, legoktm : /action/paths is interesting but beyond the scope of this RFC. Personally I find tacking on a query string to a /wiki/PageName would save me a lot of time and makes URLs friendlier and hides the /w/index.php implementation, so I'm all for it. [21:09:54] spagewmf: why is it out of scope? [21:10:13] for the record, /wiki/Foo?action=history already works [21:10:19] legoktm: the RFC doesn't propose it. [21:10:24] IIRC we can't use $wgActionPaths as it is, since it conflicts with $wgVariantArticlePath which we use extensively [21:10:59] #info for the record, /wiki/Foo?action=history already works [21:11:10] legoktm: agreed it works, so this is just making the generated links follow that form. [21:11:16] you would at least have to dream up a path mapping for variant wikis and implement that [21:11:41] roll over the links in the tabs at the top of a page [21:11:47] /{variant}/{action}/{title} ? [21:11:59] and for non-variant wikis /{action}/{title}? [21:12:39] something like that [21:13:11] this RFC is not just about generated links, it is also about squid/varnish purge URLs [21:13:20] since history URLs are currently purged when the page is edited [21:13:39] $wgVariantArticlePath is an important thing to consider [21:14:05] you would ideally have the index.php?action=history URL redirect to the article path ?action=history URL [21:14:12] since that redirect can be cached [21:14:16] I would very much like to use it for multilingual sites like wikidata and commons, so we can allow anons to set their preferred language for the UI and thecontent [21:14:33] and so that a purge of the /wiki/...?action=history page would be cached [21:14:52] I mean a purge of the cache would be seen by the client [21:15:18] It sounds like the proposal at hand is independent of any future action path / variant path changes though [21:15:28] yes, I think so [21:15:40] is it actually ok to cache the output of any action=foo page? [21:15:49] no [21:15:53] some of the output would depend on user rights, no? [21:15:57] I'm not trying to stifle discussion of those things, just pointing out that it doesn't block [21:16:02] it depends on Cache-Control headers [21:16:06] ok [21:16:23] action=history as served to anons can be cached subject to normal purge stuff AIUI [21:16:31] (as long as revdelete/oversight purges that?) [21:16:34] RoanKattouw: well, changing url structures is disruptive so the less times you do it the better [21:16:46] and yes, obviously you can't cache a page if it has the user's name in the top right corner [21:16:57] action=history as served to privileged users can contain private data [21:17:02] ...and what TimStarling said of course [21:17:33] the nice thing about this RFC is that we are not introducing any new URL scheme, so we are not creating a b/c burden for future changes [21:17:49] Well I kind of see legoktm's point [21:18:08] The canonical URL for the history page is changing from /w/index.php?action=history&title=Foo to /wiki/Foo?action=history [21:18:12] And would potentially change again to /history/Foo [21:18:22] I don't think that is a problem [21:18:22] But variant paths are a problem there [21:18:36] I don't think it is a problem for it to change twice [21:18:45] I agree [21:18:47] we already need to support both styles indefinitely [21:18:55] also, having a common prefix for all output related to a given page is kind of nice, especially for purging [21:18:57] Especially because the action path change isn't easy [21:19:17] Because Daniel had a nice-sounding proposal for this, but consider: [21:19:29] If we move from /sr-el/Foo to /sr-el/view/Foo [21:19:38] we have to put in b/c redirects [21:19:41] TimStarling: regarding squid/Varnish purge URLs, does amending the current proposal to say the old /w/index.php?title=Foo&action=bar would redirect to the nicer /wiki/Foo?action=bar address your concern, or is there more to do to get caching and purging working right? [21:19:44] What if srwiktionary has a page called [[view]] [21:20:23] spagewmf: My gut says an additional change is necessary [21:20:32] But TimStarling knows more about Varnish than I do [21:20:59] the RFC has an alternative way to deal with caching, which I think would also work [21:21:01] Is there a specific reason we are looking to support both styles other than Varnish? Sorry if I'm misunderstanding the reasoning. [21:21:14] "By doing this rewriting in Varnish we can avoid cache fragmentation. Only URLs following the new scheme need to be purged." [21:21:21] parent5446: cool urls don't change [21:21:33] RoanKattouw: maybe we want /wiki/Foo|variant... [21:21:40] Mhm [21:22:01] Hah [21:22:02] Don't want to break every WMF wiki link everywhere by dropping the historical url scheme [21:22:04] well, it works as long as the wiki uses varnish [21:22:17] redirecting might work better for non-WMF installations [21:22:21] Why is it necessary to rewrite the URL in Varnish? [21:22:27] Yeah let's implement a redirect at the very least [21:22:33] The redirect's target will never change [21:22:39] Ah, wait, OK I was misunderstanding. My real question then is is there a specific reason we're looking to make the new scheme /action/page rather than /page/action? [21:22:48] And implementing that does not preclude a URL rewrite in Varnish, WMF can have both [21:23:09] parent5446: MW already supports /action/page, but no reason besides that I think [21:23:13] parent5446: because titles can contain slashes [21:23:13] * DanielK_WMDE_ regrets bringing up action pathes [21:23:15] parent5446: If I can have a page called [[OS/2]], I can have a page called [[OS/view]] [21:23:36] so the title has to be at the end of the path part [21:23:37] That makes sense. Thanks for the clarification. [21:23:38] DanielK_WMDE_: dont :) [21:23:55] for purging, ?action=history seems a lot easier and cleaner than /history/Foo [21:24:18] Yeah it seems like at the least we could say "when /wiki/Foo is purged, also purge /wiki/Foo?anyquerystring" [21:24:32] exactly [21:24:36] prefixes are handy [21:24:42] well, you can use vcl_hash to put everything that starts with /wiki/Foo in the same bucket [21:24:42] Also, in terms of the URI, it makes a lot more sense for the action to be non-hierarchical information than to be part of the path [21:24:54] and then purge the whole bucket [21:25:36] you can also put unrelated URLs in the same bucket using vcl_hash, it just takes a bit more code [21:26:31] ok, so any objections to approving the RFC, with the caveat that a permanent redirect should be considered over a varnish rewrite? [21:27:11] Sounds good to me. Which URL is going to be the canonical one? The new one right? [21:27:14] sounds good to me [21:27:25] +1 [21:27:35] yes, the new one is canonical [21:27:39] parent5446: yes. we already have it the other way around [21:27:43] Nice [21:28:00] #agreed RFC approved, with the caveat that a permanent redirect should be considered over a varnish rewrite [21:28:19] I'd say "in addition to" [21:28:21] TimStarling: the one thing I noticed when I manually rewrite URLs to /wiki/Foo?action=xx is https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Clean_up_URLs#action.3Draw_behavior_difference , I dunno if it's significant. [21:28:21] But sure [21:28:36] normally #agreed would be gabriel's cue to jump in and disagree with everything everyone said, but thankfully he proposed this RFC so it is not possible in this case [21:28:46] ;) [21:29:01] :D [21:30:08] #topic Assert | RFC meeting | WMF Metrics Meeting April 2015 Stream: https://www.youtube.com/watch?v=To4HLZSrp0Y | Questions/Moderator: Jamesofur | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [21:30:13] i.e. old-style https://www.mediawiki.org/w/index.php?title=User:SPage_(WMF)/test.json&action=raw works, but new-style we're approving https://www.mediawiki.org/wiki/User:SPage_%28WMF%29/test.json?action=raw gets a Forbidden [21:30:14] #link https://www.mediawiki.org/wiki/Requests_for_comment/Assert [21:30:29] #link https://phabricator.wikimedia.org/T91071 [21:30:43] I am very worried about performance impacts of something like that [21:30:49] ^my words exactly [21:30:59] #link https://github.com/wmde/Assert/tree/master/src [21:31:11] i.e. if you attach function call to every argument of every function, performance will go down the drain [21:31:18] SMalyshev: if we sprinkle it over performance hotspots, I agree [21:31:48] SMalyshev: type validations for parameters is a very good thing to do in setters and constructors. [21:31:57] i wouldn#t recommend to do it for all function calls [21:32:01] the problem is nobody knows what hotspots are, it all depends on scenario. In one scenario, retrievign foobar is once a day, in other you dump 100k foobars at once [21:32:03] DanielK_WMDE_: But PHP already has type checking [21:32:07] I remember the primary motivation was that MW does not really have a use-case for "asserts that can be turned off", so we would only use this class for assertions we are already putting in our code. [21:32:09] For function params at least [21:32:25] RoanKattouw: sure, but this isn't solely about type checking [21:32:27] RoanKattouw: PHP also has cheap asserts, but in 7.0 ;) [21:32:29] that's just one common case. [21:32:43] also, php's type checking doesn't (yet) work for string vs int vs null [21:32:49] Sure [21:32:51] https://wiki.php.net/rfc/expectations [21:32:52] also, a very common case are array element [21:33:20] SMalyshev: the reason PHP's assert() is aconsidered a no-no is because it behaves like eval() [21:33:24] You mean, assert that the array I was passed does in fact only contain strings? [21:33:43] I think that was Tim's main point last time this was dicussed on the mailing list [21:33:46] DanielK_WMDE_: I know. in 7.0 it's not anymore, but that is more theoretical for now [21:33:52] the RFC has some pointers to relevant mailing list threads [21:34:23] SMalyshev: indeed. 7.0 also has type hinting for primitive types, and return type declaration. looks like PHP is becomming a programming language ;) [21:34:43] :P [21:34:44] anyway [21:34:55] We'll be lucky if we move to 5.4 [21:35:01] the basic idea is to provide a safe alternative to PHP's native Assert. [21:35:15] I added a few conveniance functions, and a distinction between preconditions and postconditions [21:35:29] the latter isn't commonly checked, but I found myself missing the feature a few times [21:35:35] yeah but for me the main issue is that if you use it rarely, it doesn't help much [21:35:49] the idea is that this library would be pulled into the core via composer? [21:35:54] i'd like to promote strict param checking for constructors and setters, using the new Assert class [21:35:55] i.e. you check random stuff, but if you don't do it consistently it's just random stuff [21:36:00] TimStarling: yes [21:36:31] and if you use it massively, you get performance hit in production where it's not really needed that much [21:36:35] SMalyshev: indeed. so push for it being used in constructors and setters. avoid using it in performance hotspots [21:36:55] constructors and setters can very well be in performance hotspots [21:37:03] depends on what you're setting :) [21:37:06] some might. but that should be rare [21:37:24] i'm not saying we should sprinkle the code with asserts now [21:37:38] I guess it depends on where you recommend to use it. I.e. the RFC kind of implies you should decorate all/most of your functions with pre/post conditions [21:37:40] i'm just propsing a nice tool to use when you want to assert something [21:37:53] I'd like to think that this library should not cause performance issues as long as the code is designed properly. If the interface speaks to most of the preconditions, then this library is only necessary in complex cases. [21:38:09] parent5446: indeed [21:38:31] SMalyshev: if it reads that way, it's my fault for not making clear that this is not what i intend at all [21:38:54] as a tool I'm ok with it, provided that it is used sparingly [21:39:04] people have been trying to use assert() and have been told off. there are good use cases for assertions. so it would be good to have a nice tool for them. [21:39:09] DanielK_WMDE_: 1) could your assert Class eventually move to using the improved php 7.0 assert, i.e. is it likely to be future-proof? [21:39:39] DanielK_WMDE_: 2) I'm surprised there isn't a PSR for this sort of thing already [21:39:45] spagewmf: that'd be hard since 7.0 assert has this trick of accepting expression and not expression result [21:39:49] spagewmf: it could be ported to use that, but yo uwould be missing out on the "cheap" aspect and probably more features of the language construct [21:39:58] My only objection is the fact that it is a class with all static functions. If the class is not going to be instantiated, then it might as well just be a bunch of functions in a namespace. [21:40:08] (But that's kind of semantic, and not too big a deal.) [21:40:12] i.e. assert($foo == $bar) would not calculate the result if assertions are disabled. You can't do it in user class [21:40:40] parent5446: namespaced functions sound nice. could do that too, if it's preferred [21:40:57] luckily, it's not only semantic, it's semantically equivalent, so it's really just syntax ;) [21:41:12] If it's going to be a Composer library anyway, it will work just the same way, so shouldn't be that big a switch. [21:42:00] would it be useful to have an RFC about a guideline for the *use* of assertions / parameter checks? [21:42:20] just a doc comment should be sufficient [21:42:32] in the class itself? [21:42:32] I'm kind of unhappy about the fact that there are 4 functions all doing essentially if(!$condition) { throw } and only throwing different exceptions [21:42:38] yeah, in the class [21:43:14] SMalyshev: different exceptions indicate different kinds of failure. but perhaps that aspect is a bit over-engineered. [21:43:15] do we even need 4 types of exceptions? [21:43:22] have you thought about accepting closures as conditions? I wonder why assert() doesn't do that [21:43:36] ^ [21:43:38] i had not considered it yet [21:43:45] i.e. who would say "ok, if its postcondition fail its bad but precondition fails are ok, no problem"? [21:43:46] it sounds appealing, but ambiguous [21:44:00] I mean, that raises an even bigger question about performance, but wouldn't be that hard to support. [21:44:07] in the case of parameter checks anyway. should work for a generic assertion [21:44:30] this assumes that we want to have configurable assertions, and I'm not sure if we do [21:44:36] Also, fwiw, I support the many different functions. It makes the code easier to read. Yeah, maybe it can be done with a constant instead, but it's not that big a difference. [21:45:16] so, how do you all feel about namespaced functions, instead of static methods? [21:45:26] And there's a difference between pre-condition and post-conditions failing. Pre-conditions failing means the callee did something wrong, whereas if a post-condition fails it means something bad happened inside the function. [21:45:32] many functions maybe ok, though I don't see too much point, but many exceptions looks like overkill [21:45:59]