API suggestion for symmetric conventions

[MehdiK]

As much as I love the power symmetric conventions provide I think their difference makes them confusing. For example I love ClassTypeHasSpecificNamespace but it's the only convention that takes a type filtering predicate.

I think it would be more consistent if we removed classType and classIsApplicable from constructor. We could have a SymmerticConvention class much like the Convention class with an Is method and also an ISymmetricConvention for Convention where the Execute method accepts a preciate in addition to those required by Execute in IConvention. SymmetricConvention could then accept a predicate required for symmetric logic which is passed into the Execute method.

Thoughts?

[kkozmic]

Hi Mehdi,

I agree with you on the fact that I'm not exactly a fan of ClassTypeHasSpecificNamespace having parameters. There's definitely room for improvement there, to make it less confusing and more in-line.

I have some ideas on how we might improve on that, but sadly haven't been able to dedicate much time to the project over the last few weeks.

If you look through history, you'll see that we attempted something similar to what you're proposing, however I strongly feel separate SymmetricConvention class hierarchy is not the right way to go.

Specifically, in what they do symmetric conventions are hardly different from non-symmetric ones and they don't deserve being an explicit, parallel universe.

Also I imagine a scenario where users might want to use the same convention symmetrically and not.

For example I might want all my Views to live in a given namespace, but I don't care what else lives there.

I think we should concentrate on making them stand out less, not more, and being natural, no brainer to use.

[JakeGinnivan]

My idea behind ClassTypeHasSpecificNamespace was to show how people could easily create a convention which doesn't quite fit into the current API (which is why it has a filter in the convention ctor).

As @kkozmic said, my first attempt at symmetric conventions went down the road of a separate interface and overloads specific to symmetric conventions. This felt like a lot of work to maintain in the long run.

TBH i think we need to create 3 or 4 symmetric conventions then try to simplify all of them by adapting the CT api.

So, what other symmetric conventions could we put in the box to try?

[JakeGinnivan]

I am writing a symmetric convention for Shouldly, we have Should.Throw static methods and now .ShouldThrow extension methods. All overloads should match.

This is what it ended up looking like. https://github.com/shouldly/shouldly/pull/252/files#diff-eb10efae6035000b7610595c5b728ddeR23

Thoughts?