-
-
Notifications
You must be signed in to change notification settings - Fork 540
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
[API Proposal]: Parsability of strings #2632
Comments
I didn't even know about |
To be honest, I don't know what to think about it. From a user perspective, it makes sense to want to support it to have simpler tests and better and more meaningful failure messages. In the past, how did you decide what makes a good candidate? Is it simply a matter of what is popular, common or heavily use? Since it was added to .NET 7, is it still too soon to consider? My guess is that the Assuming that a
Which one of the 2 static methods the code would have to invoke? Is it important? Do we have to offer a |
We would have to add a target for
The point is to verify whether the type implements |
A combination of multiple considerations.
Our users use Fluent Assertions even with previews of .NET, see e.g. #1047
That is done at compile-time via the suggested generic constraint
I think we should assume that I imagine the flow would be something like:
|
This is a logical expectation considering how the dotnet/runtime has implemented the interface themselves.
I pretty much had the same kind of flow in mind. |
.NET 7 is already out of support, so maybe it's time to target .NET 8 as well.
They are two different methods, with potentially two different implementations. So that's why I was suggesting that a |
I'm beginning to think we're moving to close to implementation details 🤔 E.g. If I wanted to test that both |
That's not exactly the same here. We're talking about a single interface that has two methods. If |
To me we must assume that e.g. string subject = MethodReturningStringifiedGuid();
subject.Should().BeParsableInto<Guid>(); |
But what does it mean to be parsable to a GUID. Does it mean that you can call |
It doesn't matter, that's an implementation detail to whoever implemented And as we don't know if the |
Then what is the point of this API. We could be using |
So if I understand you correctly, then your concern is about whether or not |
As I understand it, the point of this API is given a correct implementation of If someone implements |
Yes. But with @jnyrup's response from 4 hours ago, I'm wondering what the goal of the API is. Is it to verify whether an implementation of |
@jnyrup's explanation fits my intend with the proposal. |
I have been thinking about it too. I came back to the basics and thought about the purpose of Fluent Assertions and the goal of this proposal. Fluent Assertions has better failing messages and helps the developer by giving more contextual informations about a failing test. If we replace the We could argue about whatever it should use In case of failure, I guess we would like to have a message that says something like: "Failed to parse input 'blah blah blah' to type XYZ because ...". Should we care about
In the previous example, the return type of the input function is Here, I am probably getting to far into abstraction, but earlier I mention type |
OK, I think that settles the discussion for me. As far as I'm concerned, I think internally we call |
Background and motivation
In .NET 7 static abstracts Members for interfaces were introduced.
One of them is the
IParsable<TSelf>
interface.Currently there is no direct support to test for parsability.
To see if something can be parsed, one would currently have to call
Invoking(<call specific parse here>).Should().NotThrow()
, which seems a bit clunky, adds more overhead then necessary and (depending on the targeted type) does not always provide a helpful and clear failure reasoning.The use of Invoking also results in loosing the reference to the original string inside of the call-chain.
API Proposal
API Usage
Alternative Designs
other names that came to me were:
(Not)ParseInto
(Not)BeParsableAs
Risks
None that I know of, unless adding .NET 7+ support itself should be considered as a risk-factor.
Are you willing to help with a proof-of-concept (as PR in that or a separate repo) first and as pull-request later on?
Yes, please assign this issue to me.
Edit:
The text was updated successfully, but these errors were encountered: