Closed DarthSharkie closed 2 months ago
Build failure is expected, not all classes were updated. That will be handled if I take this forward.
I also believe this helps lay the groundwork for #34, as the logic to handle multiple interceptor functions at each extension point can be centralized in ParticleObject
.
Working on rebasing this; I think it will produce safer, easily stackable interceptors.
We've discussed interceptors and their complexity, extensibility, and type safety a fair bit. I think this PR lands us in a good, maintainable, explainable, flexible state.
Right now, it only modifies a few of the particle objects (those that use custom metadata) to demonstrate what is possible with metadata
Key
and values. It doesn't quite get to theMetadataEntry
we briefly discussed, but I think that's OK given the compile-time type safety afforded by this solution.This approach relies on Java's reflection capabilities around understanding generics and subclasses. Fundamentally, every
key
stored in the metadata must be a subclass ofKey<T>
that is explicitly spelled out; i.e., cannot use a generic method to define the subclass once for everyone. This is due to Java's type erasure, which results in treating all instances of that subclass as equal, which we do not want. Rather, we need the approach taken by C++ where every separate parameter type results it its own definition of the subclass. This sounds verbose, but it's very succinct and easy to understand/repeat, as Java uses anonymous subclasses commonly now due to lambdas.This PR did manage to combine one other change I think we need, which is removing the type parameter from
ParticleCombiner
, since it doesn't help clarify anything. This is not a good practice from me to do this, so I will plan to break it into a separate change, assuming the general interceptor idea here is reasonable to implement across the rest of theParticleObject
subclasses.I'll also plan to squash the commits below, since the first two were exploratory ideas that didn't really work out.