copper-leaf / copper-leaf/common

Create a model around the fields that can be extracted and cache it per-class

Open
#4 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
1
Forks
2
PR merge metrics
No merged PRs in 30d

Description

Creating a model around the fields that can be extracted allows us to cache it and re-use it for every class that wants to extract options into a given object, so that future extractions of the same type do not need to navigate the type hierarchy or instantiate the same Archetype over and over, improving speed by limiting the usage of reflection.

This model should also be able to be used to inspect the contents of a class, so we can generate documentation for the extractable properties of that class. It should also integrate seamlessly with the Annotation Processor such that the Processor generates these models that populate a class that is not based on Reflection. If there exists a Processor-generated model for this, it gets cached upon its first use, otherwise a reflection-based model is generated at runtime. In all cases, the cache takes precedence over the processor-based or reflection-based models, allowing you to provide your own model implementation if desired/needed (for example, creating non-reflection based models for expensive classes in another library).

This model should be immutable and thread-safe. Once generated, you just need to pass an instance of the target class to it, and the result will be an injected object. Open to discussion is whether these models should be hierarchical, where one model passes the object along to the models for its superclasses, or flat, where each model does the work for the object and all its superclasses without referencing any other models. The first probably better and would have less duplication of code, but might produce a lot of entries in the cache, and it might cause strange behavior when a subclass overrides a field in a superclass. The second would have more duplication, and for manually-created or generated model implementations, might become stale and not always work as expected, and would also increase the size of the jar, but would likely result in a smaller cache.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.