search

Mutagen-Modding / Mutagen.Bethesda.Analyzers

A project to diagnose and analyze the health of a mod or a load order
GNU General Public License v3.0
16 stars 5 forks source link

ContextualAnalyzer typed link cache #154

Open Noggog opened 2 weeks ago

Noggog commented 2 weeks ago

To help scope what contextual analyzers might look up, they could type the secondary record types it looks up and offer link caches that can only look up those types.

This would also allow these analyzers to offer FieldsOfInterest() for those secondary types

Elscrux commented 2 weeks ago

Do the available types in the link cache need to be connected to other fields of interest? Couldn't we just add more fields of interest independent of any of that?

Noggog commented 1 week ago

How would you specify which type a FieldOfInterest is relative to? For record analyzers, the type is the record they're targeting so x => x.SomeField can be written relative to that.

For true open contextual analyzers, we'd need to offer a different way to specify FieldOfInterest where the user could specify (any) type and then write the interest path.

I could see us having a different FieldOfInterest method signature that allowed for variable interest input types. (object input or something nasty?) That's one route, especially if the amount of things referenced was insane. But I'd view the fully "open form" route as a safety fallback choice?

Another way to do this is to have ContextualAnalyzer alternatives with a few flex generics. A contextual analyzer that is going to look at Npcs, then resolve their Races and do some comparison might do: IContextualAnalyzer<INpcGetter, IRaceGetter>, where this interface had a FieldsOfInterest per record type.

Paired with #152 when someone resolved the IRaceGetter, the corresponding FieldsOfInterest of that type could be used.

Elscrux commented 1 week ago

I see a lot of possibilities for analyzers that are taking many records into account, not just a second or third type. Sometimes it might also not be a specific major record type but a link interface or so that needs to be referenced. That's why I think this should be a very open kind of way to declare fields of interest. Tying it to the analyzer class itself feels quite limiting and would require more refactoring work when changing parts about the analyzer. Am I seeing it correctly that it is just about the (types of ) records to watch, and not adding any addition functionality to the analyzing part? You just use the link cache as usual?

Noggog commented 1 week ago

General discussion over here #153

But for this one specifically, yeah, it might not offer much now besides forcing the user to define FieldsOfInterest for all record types involved, and not letting them query the link cache for types that they havent also defined FieldsOfInterest for.

Helps avoid the "oh, forgot to do that part", as it literally wouldnt compile until they defined something for it