Refactoring

[leo60228]

post ideas and stuff

copied from discord:

tbh I thought about splitting MonoMod into pieces MonoMod.Patcher for the patcher and relinker, MonoMod.RuntimeDetour for the runtime detour part, MonoMod.DebugIL for the DebugIL dumper, ... I basically wanted to get to it once I'd begin working on something called MonoMod.BaseAPI or BaseLoader the name is still open, but it'd be a collection of all the mod loading / mod API - related parts I've worked on for years now stuff that began in FEZMod and that has been carried over through ETGMod over YLMAPI (which never became a thing, sadly) to Everest HookedMethod would then only depend on the MonoMod.RuntimeDetour library [...] it's meant to be a patcher in the first place, yes, but it's also meant to be a library to make C# modding easier this is "feature creep" territory, but honestly, I'd like to collect everything C# modding-related I've worked on that could be useful for others in "MonoMod" in one form or another - 0x0ade

so, for that idea:

• MonoMod.Patcher: Patching thing, what Everest uses
• MonoMod.RuntimeDetour: Contains NativeDetour and supporting classes
• MonoMod.Utilities: Contains module-agnostic support (like MethodInfoWithDef and GlobalNamespaces, current name for the backing behind EventHooks)
• MonoMod.Hooks: Contains SimpleDetour (Detour now), MethodHook (HookedMethod/Hook now), and extension methods for GlobalNamespaces that provide "EventHooks"
• MonoMod.DebugIL: Don't know what this is, but it exists
• MonoMod.LoaderUtils: Stuff like a mod-loading-focused relinker
• MonoMod.SimpleLoader: Wrapper around all other modules (except maybe MonoMod.DebugIL) to provide a simple, modifiable, universal mod loader not on Nuget
• MonoMod.Compat: An ILMerge/ILRepack'd .exe that's backwards-compatible with pre-modular MonoMod

@0x0ade

[leo60228]

@0x0ade I just made this repo public

[0x0ade]

I just sat down at my PC.

This would be better fit in the MonoMod repository, but on the other hand, I don't want to set this into stone just yet. Before you're going to ask: No, I'm not planning to use GitHub Projects for MonoMod just yet, as I don't see the need to "overmanage" MonoMod in its current state. This is going to be different when I want to make MonoMod easier to contribute to, but right now, getting contributors on board would only make us step on our own feet.

• MonoMod.Patcher will probably just be called MonoMod, as everything else are extensions around the MonoMod "core."
• MonoMod.RuntimeDetour should also contain Detour. Not going to rename it to SimpleDetour, as calling it "simple detours" sounds wrong. Is it "simple" to use? Or is the implementation "simple?" Maybe it can only achieve "simple" tasks? Detours are the lower-level foundation of Hooks, which should rather be used by modders.
• Personally, I'm not a huge fan of MethodInfoWithDef (one shouldn't mix Reflection and Cecil) and GlobalNamespaces would be better fit in MonoMod.Hooks (I don't know what its purpose is, though). MonoMod.Utils can contain everything else currently in the MonoMod.Helpers namespace: Platform + PlatformHelper, ReflectionHelper, StringInjectExtension and any other useful extension methods / helper classes that we "collect" on our way.
• I'm fine with rebranding HookedMethod into MonoMod.Hooks, but I'm leaving this to you :) Probably not going to maintain it too heavily myself.
• MonoMod.DebugIL is a very small helper, but it being its own tool is also something I've had in my mind for a while now.
• MonoMod.LoaderUtils and MonoMod.SimpleLoader should just be MonoMod.Loader. Once again, drop the "simple", otherwise we could as well rename MonoMod to SimpleMod. A fully "universal" mod loader is impossible - our task should be to provide the foundation and tools to build a mod loader. And those tools should be provided in MonoMod.Loader.
• MonoMod.Compat: We're probably going to break backwards compatibility in unexpected ways, but if we're going to try to keep old mods functional, we should attempt to use TypeForwardedToAttribute instead.

[leo60228]

Oh, I thought you meant MonoMod.Loader to be a mod loader template, and thus I thought it would make sense for relevant utilities to be in a separate project (in the C# sense) exposed on Nuget.

[leo60228]

GlobalNamespaces allows this syntax: GlobalNamespaces.System.String == typeof(System.String) && GlobalNamespaces.System.String.GetType() == typeof(ExtendableType /* working name */)

[leo60228]

ExtendableType is a DynamicObject because extension properties don't exist yet

[0x0ade]

I'm still undecided whether MonoMod.Loader is going to be a template or not, which is why I was hesitant to announce my plans publicly :/