In an effort to bring Marie Kondo memes to dev-platform, I'd like to propose an XPCOM tidying project.
Through DeCOMtamination, Quantum, Fission, and other projects, we've managed to un-hide quite a few headers to C++ classes that would've otherwise been only accessible through XPCOM interfaces, made more interface members infallible, etc... I'm running into quite a few cases of this lately, and was considering making a metabug for XPCOM Tidying. Tidying would be an effort to reduce the footprint of XPCOM interfaces, for interfaces that have some obvious interface implementation. It's a step back from full DeCOM, as many times we still need XPCOM interfaces for chrome JS work. This also wouldn't be a set of hard and fast rules for all XPCOM, but rather ways to clean up what we can, when we find that we can. It would serve as a task list for things that can be done as our dependence on XPCOM continues to change. For instance, this week, I've made a version of nsIURI::SchemeIs that is now infallible (Bug 1518956, followup at Bug 1518964 for more convenience functions), and made nsIPrincipal::GetURI() infallible, though that needs to be turned into BasePrincipal::URI() (see Bug 1519257). I'd imagine this tidying project being a top level metabug, with metabug children for certain rules: - Removal of [noscript] methods in interfaces in favor of direct calls via Cast() where possible. - Direct getters through Cast() where possible, infallible (also where possible) otherwise. - Converting XPCOM const lists to the new XPCOM enum type. - Removal of accessors for C++-only accessed members, where possible. These would need to be metabugs because sweeping some of these changes across the codebase in a single bug would be infeasible from a review standpoint. For instance, trying to change out SchemeIs() to use the cleaner infallible version everywhere would be a huge undertaking in a single bug, but could be tracked per project directory or similar work unit in smaller bugs (i.e. bug 1518986). This also wouldn't be considered a single person or team's project, just something that could be referenced when working on different parts of code. While it could be a good source of good-first-bugs or contributor input, some of the logic changes here can get pretty hairy, so it's not a perfect fit for that. This would probably end up continuing making XPCOM interfaces look more like a guide to shared parts between C++/JS than the template for all access that is has been for years. As XPCOM has been around far longer than I have and therefore may involve both opinions and uses I may not be aware of, I wanted to present this idea to the list first and ask for feedback. Please let me know what you think. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
