From discord
Ok so, I gave the mixin idea I proposed some more thought, and decided that the actual value proposition is being able to detect when you'll load a type not defined in your assembly or your optional dependency's assembly in an if ModHooks.GetMod(modname) is Mod block.
Then I realized this is actually statically analyzeable! So it could be a Roslyn source analyzer distributed as a nuget package (and referenced by default by certain opinionated templates).
Process:
- Use syntax analysis to match blocks of the form
if ModHooks.GetMod("some mod") <any valid presence check>
- Search your dependency tree for a subclass of Mod which has a matching name. If not, pass analysis.
- Read the content of the if block and collect 2 things: (a) all referenced types and (b) all method calls
- Do type analysis. For each discovered class, check properties, fields, and method signatures for additional types. Types in any assembly that does not define a Mod, and the assembly found in step 2 are ignored. Queue types defined in your own assembly for further investigation. If any types not already covered by these cases are found, flag down the offending line(s) and issue a compiler warning. Repeat this step until the type queue is exhausted.
- Optionally, check the content of the method calls, repeating steps 2-5 until all the called code under the if check is exhausted. This may be super expensive though and the first 4 steps (that only check for n=1) would catch probably well over 99% of bugs
From discord
Ok so, I gave the mixin idea I proposed some more thought, and decided that the actual value proposition is being able to detect when you'll load a type not defined in your assembly or your optional dependency's assembly in an
if ModHooks.GetMod(modname) is Modblock.Then I realized this is actually statically analyzeable! So it could be a Roslyn source analyzer distributed as a nuget package (and referenced by default by certain opinionated templates).
Process:
if ModHooks.GetMod("some mod") <any valid presence check>