-
Notifications
You must be signed in to change notification settings - Fork 476
Description
I think we're almost ready for another release.
- The PRs Draft: Add support for by-ref-like (
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. - PR Add support for default interface members in inheritance-based proxy types #661 is not a draft, and I'm hoping we can include it here. But if it needs more work & time, we could also do a release 5.1.2 without it instead.
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:
- whether or not (and how) to extract deprecated DictionaryAdapter into a separate project (Future of Castle DictionaryAdapter #394);
- whether or not to abandon (especially binary) serialization of DynamicProxy proxies (Remove support for serialization? #562);
- what to do about the logging abstractions & integration packages (Future of Castle logging abstraction and adapters #408).
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.