Repository navigation
API suggestion for symmetric conventions #34
Description
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?
Activity
kkozmic commentedon Sep 19, 2013
Hi Mehdi,
I agree with you on the fact that I'm not exactly a fan of
ClassTypeHasSpecificNamespacehaving 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
SymmetricConventionclass 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 commentedon Sep 21, 2013
My idea behind
ClassTypeHasSpecificNamespacewas 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 commentedon Jul 4, 2015
I am writing a symmetric convention for Shouldly, we have
Should.Throwstatic methods and now.ShouldThrowextension methods. All overloads should match.This is what it ended up looking like. https://github.com/shouldly/shouldly/pull/252/files#diff-eb10efae6035000b7610595c5b728ddeR23
Thoughts?