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
Consider Supporting Open Generics #287
Labels
Milestone
Comments
I should also note that I want this delivered with an |
If/when I do this, update all integration tests to use open generics (and move all the attributes to the class level) |
JasonBock
added a commit
that referenced
this issue
Mar 11, 2024
JasonBock
added a commit
that referenced
this issue
Mar 12, 2024
JasonBock
added a commit
that referenced
this issue
Mar 13, 2024
…od implementations, and expectations (still fixing more)
JasonBock
added a commit
that referenced
this issue
Mar 14, 2024
JasonBock
added a commit
that referenced
this issue
Mar 14, 2024
JasonBock
added a commit
that referenced
this issue
Mar 16, 2024
…ameters and TypeArguments....brb...
JasonBock
added a commit
that referenced
this issue
Mar 16, 2024
JasonBock
added a commit
that referenced
this issue
Mar 16, 2024
JasonBock
added a commit
that referenced
this issue
Mar 16, 2024
…ReferenceModel values, and create a GetFullyQualifiedName() to make it easier to make names
JasonBock
added a commit
that referenced
this issue
Mar 17, 2024
JasonBock
added a commit
that referenced
this issue
Mar 17, 2024
JasonBock
added a commit
that referenced
this issue
Mar 17, 2024
JasonBock
added a commit
that referenced
this issue
Mar 17, 2024
JasonBock
added a commit
that referenced
this issue
Mar 18, 2024
JasonBock
added a commit
that referenced
this issue
Mar 19, 2024
JasonBock
added a commit
that referenced
this issue
Mar 19, 2024
JasonBock
added a commit
that referenced
this issue
Mar 19, 2024
JasonBock
added a commit
that referenced
this issue
Mar 19, 2024
JasonBock
added a commit
that referenced
this issue
Mar 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the solution you'd like
Rocks has always forced users to close generic types. For example, if you had this:
You had to provide types to create the mock:
I know there are reasons why I forced this and didn't support open generics, but....with the new approach of using attributes on the way, I think it's worth revisiting. You'd still be able to pass in closed generics, but I think this is possible:
I'll add a code example in a follow-up comment. But, I think this is possible. And the generated expectations name is cleaner to me:
IServiceCreateExpectations<T, TReturn>
. Furthermore, you wouldn't have to generate mock code for each closed generic; you could specify you want this, and the types could be specified when you start creating expectations. Here's a code dump of a POC (I've already verified this would pass the test :) ):The text was updated successfully, but these errors were encountered: