daniel added a comment. Next step for resolving this: add a service locator to MEdiaWiki, to provide a "composition root" for the dependency injection. This is being tracked as T124792: RFC: Service Locator for MediaWiki core. <https://phabricator.wikimedia.org/T124792>.
Session notes: https://etherpad.wikimedia.org/p/WikiDev16-T119032 (scroll down to "Dependency injection"). Transcript: ------------------------- - Rationale: avoid strong coupling, decouple dev, improve testabiltiy, and higher re-use - Services with narrow interfaces - Needs a top level service that glues them all together - Recent RFC discussion about this. Some consensus was reached. - How should services configure their containers? - Should services be able to detect what wiring they need? Some people are against this - Shall we use a pre existing framework or roll our own? - Current frameworks do too much. Not worth the pain of depending on a third party Questions: - Timo: Avoid gloval variable rather than singletons - Daniel: Avoid access to static variables and global scope. We don't want to modify all the hook signatures - Chad: Avoid 3rd party framework if we will only use a fraction of it. PHP tends to do auto-wiring with reflection. What is the overhead of this? Biggest comparsion is java - Daniel: It would happen on every request. Orginal RFC suggested auto-wiring with performance being a big concern. Too much magic. - Chad: Avoid auto-wiring because its too magical. Can be nice for quick writing of scode but the magic can be scary. - Daniel: I agree - Timo: We've had to remove reflection in codebase - [missed question] - Kunal: Main concern is how we're goign to get people to use this. No one is using TitleValue - Daniel: Several problems. Doesn't have all the info from the page table. With a DI framework you would have hub for services - ChrisS: Auth plugin kind of worked but became a bear to work with. If we do them right then yes but we design them with a rigid interface that ends up not working well. Caution agaisnt extensions depending on these interfaces. Vote no due to auth plugin experience - Daniel : Maybe an interim solution of a whilelist of what can be replaces - ChrisS: Need to document the security properties and wether is standard docs or within the class itself - KatieF: Would be nice to define a formatter for these new types coming from extensions - Timo: Using a library as a pattern but not a framework - RobL: How do we more forward with these two areas? - Daniel: What should the role of arch comittee be with this? - Greg: Why is the arch comittee not driving this forward? - RobL: They are overseeing it but others need to be involved - Daniel: We need time and resources. It won't immediately help build shiny new features. No one is responsible for building this kind of thing - Katie: As people have time we can tackle this - Chad: Not hearing any real objections but instead a resourcing issue. No one truly own nebulous parts of core like this. Should we give the arch committe the resources to own this? - RobL: Whenever we have a hard question we say that we should just throw resources at it. This is a cop-out. We don't have huge budget to do these things. Some of these don't require full time resources - Daniel: Need to follow principles and not make the problem worse - Greg: We need to make this a project that a team owns. Need to elevate arch decisions to the same level as user facing features - Brad: Speaking to lack of resources, and also the "team autonomy" point in the SOA discussion earlier: We used to have a team that was nominally responsible for stuff like this. But the WMF Engineering Reorg of Doom™ seemed to be aiming for more team autonomy in creating these "verticals" and killing the teams that used to work across the vertical lines like this. - Ori: We're too insular to working with enterprise users TASK DETAIL https://phabricator.wikimedia.org/T384 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Addshore, Izno, Glaisher, Ricordisamoa, RobLa-WMF, MZMcBride, Tgr, phuedx, GWicke, JeroenDeDauw, bd808, Aklapper, Spage, AndyRussG, daniel, JanZerebecki, Qgil, Wikidata-bugs, aude, jayvdb, Mbch331, Jay8g, Ltrlg, Krenair, Legoktm _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
