Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Private visibility on MetadataFactory #54

Open
dominics opened this issue Jul 6, 2015 · 0 comments
Open

RFC: Private visibility on MetadataFactory #54

dominics opened this issue Jul 6, 2015 · 0 comments

Comments

@dominics
Copy link

dominics commented Jul 6, 2015

Would you consider merging a PR that increased the visibility of a few parts of MetadataFactory from private to protected? (It wouldn't necessary have to become part of the stable API - but allowing overriding of parts of the MetadataFactory will prevent me having to copy/paste large parts of it.)

My use case:

  • I'm trying to prevent a few round trips to the cache caused by a very 'deep' hierarchy of classes, all of which I know will have no metadata (the cache checks are unnecessary)
  • There's nothing overridable in the MetadataFactory that will allow me to short-circuit before the call to check the cache

I've looked into:

  • Adjusting the 'hierarchy' metadata class via constructor parameter
    • This class seems to just hold the results, and won't allow me to filter before incurring the cost of the cache round-trips
  • "Preloading" null metadata entries into the 'loadedMetadata' member array of the factory
    • This would allow the parent classes to be excluded without going to the cache, but the member array is private
  • Overriding getClassHierarchy(), which is probably closest to what I actually want to do
    • This would allow me to filter the hierarchy to the classes I care about, but getClassHierarchy() is private, so this requires copy/paste of about 60 lines - yuck

I can't seem to find a way around this, but if you have an alternative to suggest, I'd be happy to hear it. The long-term fix if you don't want to open up the internal API might be to use a strategy pattern for turning the class name into a hierarchy, so that I can override that part via DI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant