feat: add AttributeProvider #83
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
Related issues
This is an expansion upon my prior work in #74
Describe the solution you've provided
I added a new interface (AttributeProvider) and API (ContextBuilder.attributes(AttributeProvider)) which allows the developer to pass in a dynamic and lazy set of attributes. Once again, there are decent number of attributes which are available across our shared LDContexts but only a few attributes are actually used in most flags. This is a way to flexibly provide these attributes, while keeping the copy on write semantics introduced in my prior PR.
I kept the original PR's work, but renamed AttributeMap to Attributes (safe since none of it is public). I made Attributes abstract and have two implementations: one for maps (use the ContextBuilder.set() methods) and one for AttributeProvider). As seen in my new unit test case, it is possible to mix and match.
Describe alternatives you've considered
My goal is to basically to something like this in my code:
I considered adding AttributeProviderFactory, but I settled on just adding the AttributeProvider for now. I did not want the library to get too stuck to our use case, also the jdk 7 min version is troublesome to add lambda support like that.
Additional context
See flame chart analysis from prior PR. This PR would ideally get all HashMap things eliminated since the LDValues would be provided on-demand.