Iterable Matchers Depend on a Well-Defined Iterable#mkString

[GoogleCodeExporter]

Some Iterable matchers make the assumption that mkString is well-defined on
the target collection.  For example:

itr must containAll(Set('1', '2', '3', '4'))

This is defined as:

Set('1', '2', '3', '4') forall { e => itr exists { _ == e } }

Thus, the matcher intrinsically depends upon a well-behaved `exists`
function on the target Iterable.  However, the matcher also artificially
depends upon a well-behaved mkString function on that same Iterable (for
the error message).  This is not always the case.  It is possible to have a
collection which defines exists but not mkString (some classes of infinite
collections satisfy these constraints).

At the very least, `failureMessage` should be declared a `lazy val`,
ensuring that the lack of mkString will never interfere with a successful
match.  Ideally though, failureMessage should be defined in terms of
toString, obtaining reasonable error messages without sacrificing
usefulness with infinite collections.

Original issue reported on code.google.com by djspie...@gmail.com on 31 Oct 2009 at 5:31

[GoogleCodeExporter]

Original comment by etorrebo...@gmail.com on 2 Nov 2009 at 11:40

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r1160.

Original comment by etorrebo...@gmail.com on 2 Nov 2009 at 12:11

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by etorrebo...@gmail.com on 14 Feb 2010 at 2:43

• Changed state: Verified