fluentassertions
Namespace - Just FluentAssertions
https://github.com/fluentassertions/fluentassertions.json/blob/master/Src/FluentAssertions.Json/JsonAssertionExtensions.cs#L5
Should the namespace for that file be just FluentAssertions ?
Then we won't even need this message in the docs
Be sure to include using FluentAssertions.Json; otherwise false positives may occur.
I'm not sure. If we do, you might end up have collisions with the main assembly. Either way, changing this now is going to be a breaking change. cc @jnyrup
I believe collisions would only occur if the main library has a conflicting overload
In this case JToken/Value/Object
Or classname
Some observations:
All FluentAssertions extensions currently use a sub namespace, e.g. FluentAssertions.Json, FluentAssertions.Mvc, etc.
Currently without using FluentAssertions.Json
((JToken)null).Should(); // GenericCollectionAssertions<JToken>
((JValue)null).Should(); // Ambiguous between `ObjectAssertions`, `GenericCollectionAssertions<JToken>` and `ComparableTypeAssertions<JToken>`
((JObject)null).Should(); // `GenericDictionaryAssertions<string, JToken>`
I don't think it would harm to unnest the namespace as a breaking change.
I don't think it would harm to unnest the namespace as a breaking change.
Not sure what you're saying
@dennisdoomen No, that sentence didn't make an sense.
I don't think moving this extension from FluentAssertions.Json to FluentAssertions would cause major problems, as none of the three types extended on are from BCL and JTokenAssertions extends ReferenceTypeAssertions.
On the other hand, all other FA extensions are in sub namespaces, so I assume they "suffer" from the same problem.
I think the other repos could also be moved to FluentAssertions namespace.
Note that this is only the extension class containing the Should() methods
Yeah, but changing namespace FluentAssertions.Json to FluentAssertions will most definitely cause breaking changes to existing users of this extension library.