Rocks icon indicating copy to clipboard operation
Rocks copied to clipboard

Support Static Abstract Members in Interfaces

Open JasonBock opened this issue 2 years ago • 1 comments

Describe the solution you'd like This was something I thought I looked at before, but for some reason I can't find any notes. Anyway...

C# 11 added static abstract members in interfaces, or SAMIs. Part of the reason I didn't try to support it originally is that the attributes were generic, and you can't pass interfaces to type parameters that contain SAMIs. However, with the open generics feature implemented, I now have attributes that expect a Type to be passed in (typically with typeof(...)). That means I could add support for SAMIs, but there are a number of things to consider:

  • The mock type has to be public when SAMIs exist. This....shouldn't be problematic, but need to ensure that there are no name duplications. I may be able to narrow this down somewhat if we have SAMIs that are not operators, then the type will be made public (or maybe just internal). Rationale here is that if you're implementing an interface with just operators (like IAdditionOperators<,,> - https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Numerics/IAdditionOperators.cs,67cc175feb3d46df), I don't think there's a need to expose the mock type in that case.
  • If tests are run in parallel, some kind of mechanism needs to be put in place to ensure expectations on a static member work as expected. Using AsyncLocal<> may help here, though I need to do a POC outside of Rocks in testing frameworks to see if this would work.
  • Related to the previous point, I may need to make expectations disposable. The reason why is that I may need a context to clear out any underlying mechanism with expectations on static members, and having a Dispose() method may do the trick.
  • I may need to add an Operators "section" to the gen-d code, similar to what I do with Methods, Properties, and Indexers.

Describe alternatives you've considered Leave things as-is

JasonBock avatar Apr 22 '24 13:04 JasonBock

Couple of AsyncLocal<> references that I'll need to keep in mind:

  • https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/
  • https://blog.stephencleary.com/2016/12/eliding-async-await.html
  • https://stackoverflow.com/questions/49232514/why-does-asynclocalt-return-different-results-when-code-is-refactored-slightly

JasonBock avatar Nov 09 '24 20:11 JasonBock