This sounds great, perhaps an matchers subpackage would be appropriate. There you can also place the Matcher interface. Hmm, I just looked at the javadoc (no sources right now) UsingMatchers returns a CustomMatcher from many of its methods.
Perhaps an interface for this Matcher with and() and or() would be appropriate? (e.g. Combineable|ComposableMatcher?) which is then implemented by CustomMatcher. As returning concrete classes from those methods may be a problem when overwriting them or sth. Michael Do you intent to keep backward compatibility when splitting UsingMatchers? If so, how? Multiple interitance is not an option and delegating to the snippets from a aggregating class would also be quite ugly and almost as large as UsingMatchers is now? The benefit of keeping it all in a single class is that you can just use it as a superclass (e.g. execution-context) like in UnsingMiniMock or Expectation. I think Steven and Nat made some points about this in their paper on the JMock language. Perhaps putting it to a kind of class hierarchy (from the simplest at the top to the complex more to the bottom would allow to keep the source code more compact - but obviously not the resulting class). Another way may be to specifiy interfaces for all the snippets and have a dynamic proxy generated by an static method handle all the delegation stuff to the single concrete snippets - this would also be extendable or configurable. Michael On Thu, April 12, 2007 11:00 am, Elizabeth Keogh wrote: > Hi all, > > > I'm trying to add Collection and Array matchers to UsingMatchers. > > > This is now a really, really big class! > > > I'd like to split it up and delegate to the package-accessible splits, > because this will make it easier to maintain. > > The split I envisage at the moment is: > > > CustomMatcher (move to top level) > UsingEqualityMatchers (eq, isNull, isA) > UsingCollectionMatchers (collectionContaining) > UsingArrayMatchers (arrayContaining) > UsingLogicalMatchers (and, or) > UsingStringMatchers (contains, startsWith, endsWith) > UsingExceptions (pending, fail, todo, runAndCatch) > Ensure (ensureThat) > > > I think this will also be far easier to extend than what we have now, > even if we do end up rewriting Hamcrest. > > I have also added the describe(Object arg) method to CustomMatcher, which > returns arg.toString() by default. This allows me to do neat things like > "Expected a collection containing <4> but got an ArrayList [5, 6, 7]". > > > What do you think? > > > Cheers, > Liz. > > > -- > Elizabeth Keogh > [EMAIL PROTECTED] http://sirenian.livejournal.com > http://jbehave.org > > -- --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
