-
Notifications
You must be signed in to change notification settings - Fork 4
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
Get rid of vector of test objects #22
Comments
By wrapper you mean You're right, currently it's kind of annoying. The reason it is like this is because the vector was an input to the Progressively this packake is getting less automated and concise, and less powerful, and Im wondering if that was a mistake. We should probably at some stage go back having that vector of objects attached to the type via a function, then we could use it programmatically to test other interfaces. |
But I thought you agreed to that change because it allowed the interface user to define that vector of objects, instead of the interface writer? That's really important in my view |
And btw, allowing multiple arguments in an interface is quite a power boost, so it's not all doom and gloom |
The person who writes I allowed the change because the objects are only needed in the tests now and not actually used in
Absolutely! Your PRs have been great, But we do have less information available at compile time for types that implement the interface, and less concrete proof that the interface is tested - than we originally had when I first wrote it. At some point we will need to have a little discipline to hang on to or add things that on the surface seem annoying but actually have broader potential in the long term. |
I agree that it does seem a bit silly to be able to declare the interface implemented if no tests pass. So in theory, all it takes is to move |
This issue was initially about dropping the |
Yeah, it requires reverting half the changes that have been made 😅
There is a point to be made about not having the interface happen in precompile, and Im sure enforcing it will annoy some people. Maybe we can add a keyword to the macro to not run tests, like |
Oops was writing when you posted. Yeah I think TestObjectWrapper was required for dispatch back when it was used in |
Either way, I'm thinking youre right, it would be good to remove the requirement to have a vector, but to also allow it |
Not sure how to achieve that without the ugly wrapper |
At least its a hidden ugly wrapper... |
I'm back to thinking that the vector makes things easier, after implementing Its just easier if its always the same access patter - every type has a vector of test objects.
|
Sounds good! |
I feel like a single test object would make the code cleaner, eg. by removing the need for a wrapper.
The user can always make the for loop themselves
The text was updated successfully, but these errors were encountered: