You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Depending on the outcome of those decisions, we may end up with a much slimmer library and a somewhat pared-down DynamicProxy implementation that's easier to manage, so I think it would be good to start there and get rid of as much "baggage" as soon as we can.
(If we decide to keep the logging abstractions, we could take a look at #418, which should be relatively straightforward.)
I'd also love to do some code exploration about whether we really need 5 different types of proxy; I suspect we have a lot of code duplication in DynamicProxy because of that. While working on #447, that suspicion has only increased, since one of the previously distinguishing characteristics of interfaces – that they may not contain any implementation bits – no longer holds true in modern C# and .NET. The distinction between class and interface proxies may no longer make sense. (Note that instead of CreateClassProxy<TClass>(), you can already do an practically equivalent (TClass)CreateInterfaceProxyWithoutTarget<IEmptyInterface>(new ProxyGenerationOptions { BaseTypeForInterfaceProxy = typeof(TClass) })). We could potentially cut the number of collectors / contributors / generators in half with only a few minor breaking changes, and simplify the public API of ProxyGenerator a lot.
The text was updated successfully, but these errors were encountered:
Apologies to everyone who's been awaiting this release for a long time. Version 5.2.0 is basically ready, as soon as we've dealt with an expired NuGet API key, we should be able to publish it to NuGet.
I think we're almost ready for another release.
ref struct
) parameter types such asSpan<T>
andReadOnlySpan<T>
#664 and Draft: Prevent disallowed conversions betweenobject
and by-ref-like parameter and return types #665 are both marked as drafts, and will require some more work. They probably won't be finalized it time for this release.Things to do after this next release
I'd love if we could tackle those larger discussions about this library's (and DynamicProxy's) future, possibly resulting in a major version bump:
Depending on the outcome of those decisions, we may end up with a much slimmer library and a somewhat pared-down DynamicProxy implementation that's easier to manage, so I think it would be good to start there and get rid of as much "baggage" as soon as we can.
(If we decide to keep the logging abstractions, we could take a look at #418, which should be relatively straightforward.)
I'd also love to do some code exploration about whether we really need 5 different types of proxy; I suspect we have a lot of code duplication in DynamicProxy because of that. While working on #447, that suspicion has only increased, since one of the previously distinguishing characteristics of interfaces – that they may not contain any implementation bits – no longer holds true in modern C# and .NET. The distinction between class and interface proxies may no longer make sense. (Note that instead of
CreateClassProxy<TClass>()
, you can already do an practically equivalent(TClass)CreateInterfaceProxyWithoutTarget<IEmptyInterface>(new ProxyGenerationOptions { BaseTypeForInterfaceProxy = typeof(TClass) })
). We could potentially cut the number of collectors / contributors / generators in half with only a few minor breaking changes, and simplify the public API ofProxyGenerator
a lot.The text was updated successfully, but these errors were encountered: