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.
Following up from our discussion in #389 (comment), I'm proposing to make
ModuleScope
internal. This affects mainlySaveAssembly
andLoadAssemblyIntoCache
, as everything else is already internal. Those methods need new public entrypoints.Loading a previously generated assembly into the type cache
This would now be done via
IProxyBuilderWithCache.LoadAssemblyIntoCache(Assembly)
, which is implemented inDefaultProxyBuilder
.Introducing a new interface
IProxyBuilderWithCache
feels like a clean solution as long asIProxyBuilder
is a public abstraction... there could be user implementations out there (unlikely, I know) that don't have a type cache. But it might also be overkill. Perhaps it's OK if such implementations simply throwNotSupportedException
for the new load method; then the method could sit directly inIProxyBuilder
.Saving a generated assembly
This can already be done through
PersistentProxyBuilder
(on platforms supportingAssemblyBuilder.Save
).However, there would now be no way to specify the desired target file path, nor the assembly's internal name. We might want to expose those capabilities through different overloads, e.g.
Closes #389. There's still a few bits we could remove from the public API (in some cases we already have separate issues), but by and large, we're done.
P.S.: This assumes
IProxyBuilder
stays public. It if shouldn't, everything here would have to move one level up (intoIProxyGenerator
, where it admittedly doesn't fit quite as nicely from a conceptual POV).