[Refactor] Move GenerateBlastLayer logic to helper functions

[scowalt]

Right now, the blasting algorithm is stored as an Enum/string. This is used to gate which algorithm is used in GenerateBlastLayer.

This change instead stores the blasting algorithm as a BlastRadiusAlgorithm. This algorithm can be accessed and called directly from RtcCore.Radius

This change hasn't yet been tested, and it will need to be tested to validate that I didn't introduce a regression.

[NarryG]

I'm not so sure about the Func<T,TOut> method. Gonna ping @ircluzar on this one. Not sure if he'd prefer an interface, abstract class, or this Func method. I'm leaning on interface since there's other similar chunks of code (e.g. engines) that'd probably make the most sense refactored to an interface, especially with our hope to support plugins.

[scowalt]

Not sure if he'd prefer an interface, abstract class, or this Func method.

Agreed! I don't have enough context on the codebase or C# to be confident in my choice here. I'm fine with any of those implementations, and I contemplated all of them in my drafts of this change.

[NarryG]

Agreed! I don't have enough context on the codebase or C# to be confident in my choice here.

This approach definitely feels like a very C++ way of doing things. That your usual language of choice by any chance?

Long-term, components like these should be able to register themselves and just work. No wacky switch statements, no having to manually connect them to the UI, etc. What we want to achieve is component independence where you can go and make a plugin that implements some completely custom corruption logic and as long as you've filled the contract the component will just work.

This brings up a key design choice. Should components register themselves (abstract class that implements a Register() function that you can optionally override & extend if required for your specific component), or should there be some form of service that handles the registration on load? I'm not sure to be honest.

[scowalt]

This approach definitely feels like a very C++ way of doing things. That your usual language of choice by any chance?

I split most of my time between C++ and TypeScript. I know in TypeScript I would just pass around a function as an object and call it directly 😛

Regarding the rest of your comment: good food for thought

[NarryG]

So ircluzar and I spent a decent amount of time discussing this last and and as it stands, we're thinking using an interface over an abstract class and using a service to register components. The main reason for this is plugins. Once we lock down a strong plugin API, plugins should be able to extend without messing with underlying functionality. As such, we're leaning on the service approach over the self-sufficient approach. Not quite as SOLID as having the components register themselves, but due to the scope of the program (in that while it's OO, it's also very data driven), being able to manage dataflows is important.

The goal here is allowing user extensibility in a controllable way, we need to ensure we can make plugins abide by rules and not mess with the RTC too much. They'll slot into the base UI/framework in a predictable way, and the plugin maker can implement custom logic on top of that. In all likelyhood, we'll probably build out a "base" plugin that implements the contract that can be extended to achieve the advantages of an abstract class (having that base functionality in there without locking you to that base functionality).

[scowalt]

Closing this due to code rot and since I've lost context.