[19:06:35] nothing on the showcase live stream yet [19:07:09] adam hasn't hit the button yet [19:07:42] the broadcast button has been pushed [19:07:55] I can't see anything yet :-/ [19:07:58] let me know when you see yuri on the stream [19:08:04] I think there is usually a ~30 sec delay [19:08:17] oh there we go [19:08:20] thx [19:08:21] there he is [19:09:17] screenshare isn't coming across [19:09:24] ^ [19:09:30] we're not seeing it either [19:09:31] yurik: ^ [19:10:02] youtube stream is not working [19:10:07] the screen share [19:10:19] i think it's not working for the people in the hangout either? [19:10:25] k [19:10:55] moving to a different presenter now [19:11:53] :( hopefully yuri can figure it out and present at end [19:12:02] yeah I would like to see it [19:12:23] still seeing the office [19:12:27] me too [19:12:33] can you select the presenter? [19:12:36] please [19:12:37] dr0ptp4kt: ^ [19:12:48] dr0ptp4kt: can you select the screen of the presenter? [19:12:58] niedzielski: josh's screen is the presenter. what are you seeing? joakino cc [19:13:05] dr0ptp4kt: office [19:13:06] we are seeing the room [19:13:06] the office dr0ptp4kt [19:13:10] dr0ptp4kt: i just see the conference room :| [19:13:13] dr0ptp4kt: on youtube we only see the office but not ht epresentation [19:13:25] dr0ptp4kt: we see the hangout icons at the bottom too [19:13:31] done, hopefully [19:13:39] meeple27: no change [19:13:45] 30 second delay [19:13:57] now? [19:14:04] dr0ptp4kt: same [19:14:05] still no :/ [19:14:07] not for me [19:14:08] no [19:14:42] not workiiing [19:14:55] now? [19:14:59] actually, in 30 secs? [19:15:15] was it presenting yuri (at least his face?) [19:15:20] when he was speaking? [19:15:24] yes [19:15:36] until he tried to screenshare and it didn't work [19:15:40] (( [19:15:42] then it went back to the office [19:15:49] still at office [19:15:58] and stayed there, even when he went back to his webcam [19:16:05] nice office [19:16:11] yei, i closed a whole bunch of apps and it stoped showing [19:16:28] okay, i have a theory. [19:16:36] started showing [19:16:43] i'm going to mute the room audio and unmute his laptop [19:16:47] nevermind [19:16:54] yurik, it's working now? [19:16:54] still not showing for me [19:16:57] others? [19:17:02] nope [19:17:12] nope [19:17:13] yurik: are you seeing the slides? [19:17:20] dr0ptp4kt: how does hangout work?are you doing hangout from the room hangout or your personal hangout adam? [19:17:42] dr0ptp4kt, yes, but i'm viewing it via the presenter hangout [19:17:48] if you select the thumb of the laptop on the on-air hangout it should show it to us [19:19:07] dr0ptp4kt: we have audio [19:19:12] nice [19:19:16] there we go [19:19:18] dr0ptp4kt: \o/ [19:19:20] dr0ptp4kt: yea! [19:19:27] woot [19:19:56] yeah [19:19:57] works [19:20:03] "we were just building suspense" [19:20:24] participants bar is hidden for us btw [19:20:26] :) [19:20:28] when Josh was asking about it [19:20:34] it was already hidden [19:20:51] so don't freak out too much about that one on the stream ;) [19:23:23] everyone seeing trey's spreadsheet? [19:23:31] yes [19:23:36] dr0ptp4kt: yes [19:23:37] yup [19:23:38] ye [19:23:42] hooray [19:24:01] mhurd bgerstle coreyfloyd: looking super sharp! [19:24:06] will need to add order of operations for muting and unmuting to the steps table. eek [19:24:14] niedzielski: thanks! [19:24:24] and thank apple ;-) [19:26:16] dr0ptp4kt, after a reboot i think its working now, will need about 1-2 min to demo [19:26:52] yurik: ok. let's go to you next. do a 15 second description to lead in so video editing will be easier later [19:28:30] you should see yuri's screen in 30 seconds [19:28:33] guys able to see yurik's screen? [19:28:49] not yet [19:28:50] nope [19:28:54] yes [19:28:55] now we can [19:28:56] yes [19:28:56] yay! [19:28:59] yeaa [19:29:00] yay^2 [19:29:10] or ** 2 [19:30:23] or pow(yay, 2) [19:30:23] should see/hear next presenter in 30 seconds [19:30:59] working :) [19:31:02] working! [19:31:03] y [19:31:08] thx jhobs and niedzielski and joakino [19:31:58] who is doing dynamic graphs? [19:32:17] yurik: ^ are you doing dynamic graphs? [19:32:28] dr0ptp4kt, skip it [19:32:46] i was hoping to do two presentations, but its already too crazy for time [19:33:48] yurik: move it to the bottom, okay? [19:34:14] should see/hear next presenter in 30-ish [19:34:52] yes [19:34:55] yep [19:36:27] switched to replay [19:37:09] it's up on our screens [19:38:18] bearloga: that looked awesome - can you put the link to the app in the etherpad? [19:38:57] HaeB: aw, thanks! and sure :D [19:40:09] dbrant: cool shit dude! [19:40:52] dbrant: very cool! [19:41:05] dbrant: is it a java app? [19:41:07] dbrant: so when you compiling the version i can use on my dk2? :) [19:41:07] thx!! [19:41:20] working on it [19:41:36] yes [19:41:37] joakino: yep, it's basically an Android app. [19:41:46] 👍 [19:41:54] dbrant: really neat! do the planets and closer objects have their own models or are they just assumed to be spheres? [19:42:06] ebernhardson: as soon as I get one to test with! [19:42:11] dr0ptp4kt: we can hear you [19:42:14] should see next presention in 30-ish [19:42:15] we hear you dr0ptp4kt [19:42:16] we can hear and see [19:42:23] and see gergo's face [19:42:34] screen! [19:42:38] dbrant: awesome sauce(rs) [19:42:40] dr0ptp4kt: we see a picture of gergo [19:42:44] ye [19:42:49] dr0ptp4kt: screen is up! [19:43:05] niedzielski: each object can have its own mesh (i'm just using the same sphere for now). [19:43:15] who is doing "our ui library"? [19:43:16] niedzielski: and i think it supports bump maps [19:43:30] dbrant: i use mine too often lately, can't loan it out cross-continent :P [19:43:35] but super cool ap [19:44:53] next presentation in 30-ish [19:45:27] yes [19:45:31] yup [19:45:32] dr0ptp4kt: yep [19:45:37] yep [19:45:40] yep [19:46:06] dr0ptp4kt: it looks like everything works properly by default as long as the conference room (and other non-attendees) are muted [19:46:51] niedzielski: yeah, i think so, although gergo was using the room mic. but i guess in that case everyone was muted? [19:48:29] jdlrobson: you ready? [19:52:20] cool [19:52:25] yes can see [19:52:27] and hear [19:52:30] yay [19:52:30] ye [19:52:51] seeing robson's screen and hearing audio? [19:52:56] yes [19:53:19] yes [19:55:12] jdlrobson: neat! [19:55:52] attempting a tricky switching maneuver... [19:56:11] woo [19:56:20] screen 1 up [19:57:28] we're not seeing it either [19:57:51] ok screen 2 up [19:58:13] i'm just seeing a face [19:58:28] ok no [19:58:30] now [20:00:36] thanks everyone! [20:00:58] adios [20:01:52] I like the changes to the search interface a lot [21:00:18] #startmeeting RFC meeting [21:00:18] Meeting started Wed Oct 28 21:00:17 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:18] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:18] The meeting name has been set to 'rfc_meeting' [21:00:27] \o/ [21:00:41] o/ [21:00:51] \o [21:00:58] #topic RFC meeting | 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:22] so we're starting off with a quick meeting planning discussion [21:01:42] o/ [21:01:49] * aude waves [21:02:15] for the timing of next week's meeting, we'd like to keep it at 2pm SF time (PST). [21:02:19] the eventbus implementation is moving forward as we speak, so we'd like to discuss this sooner rather than later [21:02:50] one option we could consider would be tomorrow at the same time as today [21:03:04] gwicke: vaguely aware (since wikidata) is on the bugs and sounds interesting [21:03:17] the ArchCom agreed that T384 has priority in today's discussion (starting at the 10 minute mark), and we're presuming it'll take the bulk of the hour [21:03:32] this is https://phabricator.wikimedia.org/T114443, https://phabricator.wikimedia.org/T88459, https://phabricator.wikimedia.org/T116247 [21:03:40] but tomorrow is wikidata birthday party :) so probably not around tomorrow [21:03:40] ottomata: is that ok for you? [21:04:02] gwicke make the case that if we don't get around to discussing T114443 + companions, that we should have a followup meeting this week. [21:04:05] but can keep an eye on phabricator [21:04:07] can do this time tomorrow, sure, but we were hoping to get paravoid and/or _joe_ involved, and it is late for them [21:04:13] paravoid mentioned he has a meeting full day tomorrow [21:04:50] full day is hard [21:04:53] time is generally okay with me with some notice (as it's social time), but I can't make tomorrow for sure [21:05:13] ottomata: should we plan to have a T114443 meeting at a more Europe-friendly time, at the expense of SF and/or Australia participants? [21:05:27] <_joe_> I'd prefer friday if possible, time is ok for me too [21:05:31] I can do friday and I can do next week's RFC meeting as well [21:05:35] jzerebecki: would you want to discuss the Composer Streamlining RFC next week? we were thinking of scheduling it for the irc meeting (if we don't end up talking about EventBus in that slot) [21:05:38] i'd like to have ori too, as long as it doesn't expense him too much :) [21:05:40] ori: ? [21:05:49] wfm [21:05:57] earlier on friday then? [21:06:02] sure [21:06:08] this time wfm [21:06:16] oh, i can do this time friday too [21:06:21] I guess Tim might not be able to make Friday [21:06:22] I don't mind missing it, if you want to schedule it earlier, as long as you don't mind me missing it [21:06:24] so late! weekend! oh well :) [21:06:26] _joe_: ? [21:06:37] <_joe_> it's ok for me [21:06:38] oh friday is saturday for Tim, right [21:06:45] <_joe_> oh, right [21:06:49] yeah the only reason I would be working at 3am on a saturday is if the site is down for an hour or more [21:06:56] sunday is monday, though ;) [21:06:58] heh :> [21:07:04] TimStarling: there is some discussion about core vs extension for mw eventbus client, but i think that one can probably be figured out offline [21:07:11] aside from that its ok if you miss i think [21:07:42] Friday works for me [21:07:45] ok, so same time friday then? [21:07:46] alright, friday at what time? [21:08:00] T-7min+24h [21:08:03] _joe_ and paravoid are ok with this time, so that is fine with me [21:08:03] if we don't need to cater for Australia, then I'd propose earlyish [21:08:04] 21:00 UTC on Friday? [21:08:09] i can do earlier too [21:08:11] <_joe_> 9 PM UTC [21:08:24] 9 PM UTC wfm [21:08:41] +1 [21:08:47] anything but 17:00 UTC wfm too [21:08:48] DanielK_WMDE_: yes composer streamlining next week works for me [21:08:59] I love how a bunch of Europeans just said that 9pm/10pm/11pm their time is "early-ish" [21:09:00] robla: ---^ [21:09:12] okay, so lets schedule @ 9 PM UTC [21:09:14] ok, let's leave any further discussion on that for email/irc, and move on to Daniel's RFC now [21:09:21] RoanKattouw: hehe ;) [21:09:22] ok [21:09:44] RoanKattouw: on a friday no less :) [21:09:45] #topic Dependency Injection for MediaWiki core | 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:09:51] Right! [21:09:52] that's going to be at the same time a bunch of SF folks are going to be having Halloween party stuff, so attendeance will be light then too [21:09:54] #link https://www.mediawiki.org/wiki/Requests_for_comment/Dependency_injection [21:10:11] there is a phab ticket but most of the interesting stuff is on the mw.org page [21:10:13] yay :) [21:10:16] oh we can do earlier! [21:10:20] should we say 19:00 UTC? [21:10:31] 9am SF time would be fine for me as well [21:10:39] ottomata: can you own figuring out the time? [21:10:42] i have standup then, but could skip [21:10:45] robla, yes [21:10:51] that's 4pm utc [21:10:55] I wrote this RFC because I hope we can move forward a bit with dependency injection in mediawiki [21:10:56] ok, dependency injection [21:10:57] it sounds like most of the people i know i want to attend are free on friday [21:11:01] i'll just figure out calendars now [21:11:07] everybody update your calendars! [21:11:12] ottomata: let's clear room for DanielK_WMDE_ [21:11:16] k, go ahead! [21:11:17] thanks all. [21:11:33] We made some good experiences with DI in wikibase, and I hope we can use the same approach in core too [21:12:16] My only knock on this is that constructor based injection is not as easy as setter based injection in my experience [21:12:43] setter based might be ok for legacy stuff like maintenance scripts [21:12:55] "easy" meaning that if a component needs 7 services to get it's job done that's a lot of constructor arguments [21:12:55] but constructor would be nicer, generally and think it would work [21:12:56] my hope for today is to get agreement, or at least useful comments, on the 9 points i propose at the top of the page [21:13:12] Ideally we should have an approach that allows for multiple types of injection [21:13:17] (Sorry I'm late) [21:13:18] bd808: then we would want factory... and 7 is a sign that maybe stuff needs splitting [21:13:23] Yeah that's kind of why I asked DanielK_WMDE_ (about half an hour ago, so he hasn't had a chance to do anything) to add examples of how DI would be used in the receiving classes [21:13:24] in particular, i hope i can get agreement to, or at least comments, to the patches i proposed on gerrit for a top level service locator [21:13:31] #link https://gerrit.wikimedia.org/r/#/c/245483/ [21:13:45] DanielK_WMDE_: our beloved sites stuff :) [21:14:03] but agree it's the right direction for the services [21:14:10] bd808: setter based injection means your constructor has to get defaults from somewhere... and that somewhere is usually global state [21:14:20] aude: yes, indeed :) [21:14:42] right now, we instantiate a site store for wikibase client and another for wikibase repo [21:14:46] My obvious question would be why are we adding our own custom DI container and service locator rather than just using a library [21:14:47] DanielK_WMDE_: no, it means that if you call a working function before injecting the dependencies things blow up [21:14:57] would be obviously better to have what daniel proposed to have one instance for mediawiki [21:15:03] "Right now this random piece of code calls User::newFromId(), what would it look like in a DI world? Where does it get a UserLookup object from?" (Presumably via a constructor param or something but I think it'd be helpful to have that written out as examples0 [21:15:23] I like this top-level service locator [21:15:23] bd808: then calling code needs to know all the setters it needs to call. much more tricky. but i'm not toally stuck on constructor based injection [21:15:33] i prefer it, but *any* type of injection is better than global state [21:15:35] parent5446, DanielK_WMDE_ Flow uses Pimple for DI. ebernhardson knows about it [21:15:36] RoanKattouw: i think it would be from a factory [21:15:46] TimStarling: \o/ [21:15:56] User::newFromId in a UserFactory or something [21:16:00] you know I strongly promoted the idea of a singleton instance manager, but I was shouted down [21:16:10] DanielK_WMDE_: a general point: it is always a little unconvincing when the power of an architectural pattern is demonstrated on code that the person proposing the pattern has written or has been intimately involved with writing [21:16:11] calling it a service locator makes it much cooler [21:16:20] AIUI that's what Pimple has too, a singleton instance manager [21:16:32] it'd be much more persuasive if you started with something other than the site manager [21:16:33] heh [21:16:33] parent5446: i find that such libraries tend to be bloated and inflecxible. and i'm not too keen on declaring service dependency using json or whatever. [21:16:34] DanielK_WMDE_: no different than constructor args IMO. Ideally things are all mostly magically handled in the system entry points, but for things like Parser it will be different of course [21:17:00] DanielK_WMDE_: I understand, but at the very least Pimple isn't that bad. It's a lot simpler than others [21:17:19] It doesn't use config files [21:17:26] http://pimple.sensiolabs.org/ [21:17:30] parent5446: but it's not on the table for discussion [21:17:39] I like the locator part too, but am less sure about the use of globals to access it, rather than explicitly passing it in [21:17:44] is https://www.mediawiki.org/wiki/Requests_for_comment/Dependency_injection#Registry_Bootstrap an example of what an extension would do? [21:17:45] ori: noted [21:17:53] I'm all for re-using libraries but I think in this case we'll want to embrace the invisibility of a library. Passing constructor arguments doesn't require a library. Code still has to create objects and pass them around, it's probably easier to maintain if that code doesn't have dependencies (tends to infect all usage so makes librisation and re-use harder) [21:17:53] and lives inside the code directly. [21:17:57] Item #2 in the list "Objects that need access to services can only be constructed via factories" -- why? [21:18:10] #action daniel to hack up a code experiemnt porting an api module or special page to constructor based injection using the service locator. [21:18:17] \o/ thanks [21:18:28] Agreed that having 7 parameters means you should take an options object, or abstract better , maybe with an an intermediary [21:18:40] DI seems more like a pattern than a library to me [21:18:40] Why exactly is it not on the table? [21:18:41] yay [21:18:49] Yeah TimStarling [21:19:05] bd808: so that there is no strong binding between the implementations, and they can be tested separately. if service X instantiates service Y internally, you cannot test X without Y. [21:19:14] (Though Flow does use a library for it, http://pimple.sensiolabs.org/ – though I'm somewhat puzzled about what it solves) [21:19:17] but you are injecting? [21:19:19] (also, you cannot replace Y for other reasons) [21:19:21] * bd808 got lost there [21:19:29] Pimple does some clever stuff that might be worth using. See container.php in Flow for how it's used [21:19:49] how is there tight coupling in an injected dependency that inhibit testing? [21:20:16] ultimately, injection means that you are parametrizing access to needed services [21:20:35] gwicke: the locator should be accessed directly if it's not possible to inject anything. that is, in static hook handlers or constructor callbacks defined by bootstrap code. on all other levels, services, not the locator, should be injected [21:20:51] Basically the $c passed to each callback is a magical thing that implements ArrayAccess so that using $c['foo'] causes the callback for instantiating foo to be called, and that allows you do define things like $c['bar'] = function ( $c ) { new Bar( $c['foo'] ) ; } without then explicitly declaring that Bar depends on Foo [21:21:05] Krinkle: ---^^ for what Pimple solves [21:21:17] the Parser is my classic example of the need for a service locator. YOu don't know what you will need until you are mid parse and you can't inject the whole world [21:21:26] DI woudl also make testing things easier by not having code break out of its context and use e.g. use a backend directly. E.g. simply pass Hash or EmptyBagOStuff in place of $wgMemc etc. [21:21:27] #action daniel to check out http://pimple.sensiolabs.org/ [21:21:38] .oO(is #action the correct syntax?) [21:21:39] DanielK_WMDE_: I would argue that both are viable options [21:21:52] So essentially Pimple encourages a GlobalRequestContext from which everything is drawn. [21:21:59] Pimple, or at least what we use of it, is ~300 LOC, see extensions/Flow/vendor/Pimple. Really all it is is that magical ArrayAccess thing and an interface [21:22:11] gwicke: passing the locator? that would mean the code that uses it depends on *all* services. [21:22:18] Krinkle: Yes, you call Config::get( 'blahcache' ) to get the blah cache [21:22:22] (parent5446: re: why not on the table -- because the current proposal is written up in full, contains details and examples, and has patches to go with it. This raises the bar for proposing alternatives -- it's not enough (and not polite) to simply sketch out another approach that could plausibly work; it's necessary to actually pinpoint some serious defect with the current proposal.) [21:22:34] So there's a global singleton that knows how to construct everything [21:22:43] Krinkle: yes. this works quite nicely, check out the wikibase test cases [21:22:43] DanielK_WMDE_: the locator can implement several interfaces, and code could define which of those interfaces it needs [21:22:51] (That's /not/ the same as a global RequestContext necessarily) [21:23:14] gwicke: the only difference then is whether it implements X, or returns an X from a method. [21:23:17] with typed accessors, this will be type-checked as well [21:23:27] RoanKattouw: Seems like that isn't mutually exclusive with DI, as long as you call get() in the consuer of a class, instead of in the class itself (e.g. not Bar:construct: $this->foo = get(foo) but new Bar(get(foo)). But then you'd probably just want to put that factory in the code where it belongs, not all in one central place. [21:24:04] RoanKattouw: the service locator is basically a global singleton that knows how to construct everything. the important bit is to use it *only* as a last resort, and *alwys* inject narrow interfaces if you can. [21:24:06] I like this proposal, FWIW. +1 from me. [21:24:22] Sure, but it's meant to be used to facilitate DI. Look at the container.php file and you'll see a lot of stuff like $c['wiki_link_fixer'] = function( $c ) { return new Flow\Parsoid\Fixer\WikiLinkFixer($c['link_batch'] ); }; [21:24:29] Krinkle: there is no difference between a service locator object and a dependency injection container [21:24:38] the difference is in how you use them [21:24:40] gwicke: I think you are arguing for auto-wiring and in my personal past experience this becomes a nightmare. Spring auto-wiring of dependencies based on interface type becomes very ahrd to overload for a non-typical use case in Java land. [21:24:46] I don't feel like I have a clear idea of where the 'last resort' / 'inject narrow interfaces if you can' line is to be drawn [21:24:51] DanielK_WMDE_: there is an ergonomic trade-off there; being explicit gives you flexibility, but can also get very verbose [21:24:53] a DIC is never accessed outside initialization code [21:24:58] ori: Simply having a written proposal that looks nice and is comprehensive is not an excuse to ignore alternatives. The RFC has *one* sentence concerning third party implementations, and that is the intro sentence. My flaw with this RFC is that I do not see any conclusive argument against using a third party library, and as such my stance that we should use an external library rather than waste effort on maintaining our own is [21:24:58] still valid. [21:25:09] #info Krinkle: there is no difference between a service locator object and a dependency injection container; the difference is in how you use them [21:25:34] bd808: i agree, auto-wiring please! [21:25:41] tgr: I agree in theory, but I think a container requires much higher decline to avoid tight coupling. Something I don't expect "us at large" to uphold. [21:25:47] I want *no* auto-wiring [21:25:57] not sure what auto-wiring is [21:26:01] brion: only access the service locator in static context. never in an object. [21:26:12] I mean explicitly passing in an object implementing a set of factory interfaces [21:26:13] the container deciding what implemention of an interface to inject [21:26:19] we have a lot of legacy code, you can't change everything at once [21:26:27] brion: if it's an object, ask for a narrow interface in the constructor. [21:26:28] ori: the problem with not using a dependency injection container (it is not entirely clear to me whether the current proposal says that) is that changes become very cumbersome [21:26:28] decline * discipline [21:26:46] I think that's part of the reason why we don't have much DI-style code, it's hard to know where to start [21:27:04] with a top-level service locator you at least have a migration path [21:27:25] ori: object A creates B which creates C which creates D, you need a new service in D, you need to go through and update the whole chain [21:27:25] TimStarling: with top-level, you mean in global scope? [21:27:36] in new code, it should presumably never be used in an object [21:27:52] in old code, there will be more uses for it [21:28:13] TimStarling: that's the idea, yes. one dirty trick i have used for migration is to access the locator in the construcor of classes that should have the respective service injected "really soon now". works great as an intermediate step [21:28:20] I agree with TimStarling, primarily because I've done it before, i.e., making a global-level service locator and slowly migrating more and more of the codebase into it. [21:28:22] TimStarling: the typical migration path is optional injection parameters which default to calling the service location [21:28:23] so our traditional code tends to be factory-driven; Foo::newFoo() gives you the appropriate implementation subclass, if subclasses are appropriate. The service locator just looks like a big global factory to me. [21:28:27] gwicke: yes, global as in class static [21:28:31] then at some point you make them non-optional [21:29:03] is the service locator specifically key to this proposal, or is the idea of narrowing interfaces the key? [21:29:19] brion: it is in most respects. The power of it comes from removing all the other factories and centralizing the configuration [21:29:38] bd808: *nod* common config methods can be very useful yes [21:29:49] especially if overriding default implementations things... [21:29:53] leaving the "normal" code as objects that expect injection and don't know how to live without it [21:29:56] tgr: good points [21:30:24] this is how things get decoupled enough to allow testing via mocks and stubs [21:30:44] tgr, DanielK_WMDE_ : how would we transition MediaWiki's global objects to DI? [21:30:51] how do we introduce injection parameters to existing classes? [21:30:56] brion: injecting narrow interfaces into constructors is the goal (well, the ultimate goal is to avoid strong coupling). the service locator is a tool to achieve that, a tool that provides a usable migration path [21:31:11] DanielK_WMDE_: I gotta run now, but when you look at Pimple, perhaps you can also write up a short blurb about what the salient differences between Pimple and your proposal are? [21:31:37] Normally I would ask you to describe that here and now, but you've been aware of its existence for like 10 minutes so that's not fair [21:31:56] brion: if the classes are instantiated directly all over the place, you can only introduce opotional injection. if the constructor is called only in a few places, we should add a required parameter [21:31:59] Yeah, so the reason we want to split UserLookup from User is so that User doesn't hardcode where it gets Config and Database from? [21:32:05] as an example; Revision knows how to create User objects via an id or text lookup from rev_user_text/rev_user values [21:32:09] RoanKattouw: will do [21:32:10] Krinkle: Exactly [21:32:19] would we need to introduce a UserLookupService parameter to Revision constructors/factories? [21:32:27] or would that come from a common place? [21:32:28] brion: ideally, yes [21:32:45] yes (factory/service to hand out users) [21:32:46] But then how do you access UserLookup, and how does it get access to Config and Database :) I imagine UserLookup will not be static but rather a (mostly) singleton object. [21:32:52] spagewmf: which global objects? most of them could be member variables in the service locator. it would pass them into the constructors of the service objects it creates., [21:32:53] do we need separate RevisionLookupService and UserLookupService, or just a WikiService that knows all the things in a wiki? [21:32:58]