Allow introspection of matchers

[GoogleCodeExporter]

I would like matchers to allow the introspection of their structure.  I
need this for marshalling matchers into network messages.

--Nat

Original issue reported on code.google.com by nat.pr...@gmail.com on 30 Jul 2007 at 1:37

[GoogleCodeExporter]

Original comment by nat.pr...@gmail.com on 30 Jul 2007 at 2:01

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Are reflection or serialization sufficient? Or are you thinking of something 
more
specific?

Original comment by joe.wal...@gmail.com on 30 Jul 2007 at 2:56

[GoogleCodeExporter]

I'd like the structure of the matchers to be part of the public API so that I 
can
rely upon it.

Some background.  I'm using Hamcrest to implement content-based routing in an 
event
bus.  A subscriber subscribes to events by defining matchers that match the 
events it
wants to receive.  A publish advertises events by defining matchers that match 
the
events it will publish.  The event bus routes matching events from publisher to
subscriber.

The system needs to marshall subscriptions and adverts to send them between 
event
routers.  I can't use reflection and serialisation because the event bus must 
support
other languages (Python, C, and more).  So I have custom, cross-platform 
marshalling.

At the moment I'm writing my own set of Matchers that expose their structure as
public final fields and a corresponding set of marshallers that can write those
matchers into messages.  However, all but one of my matchers is duplicating the
implementation of existing Hamcrest matchers.  It seems a shame that I'm unable 
to
reuse the Hamcrest implementations.

Original comment by nat.pr...@gmail.com on 30 Jul 2007 at 3:02

[GoogleCodeExporter]

Original comment by nat.pr...@gmail.com on 30 Jul 2007 at 3:03

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I had a similar requirement a while back: I was writing a "solver" that would 
try to
come up with a value that would match a given Matcher.  In the end, I found out 
that
describeTo, with an appropriate Description, is brilliant at this.  I would 
rather
fix the few places where describeTo is not sufficient (for example, describedAs 
loses
information) than introduce a new requirement.

Especially because finding a re-use for the describeTo method, which I had 
previously
regarded as quite possibly overly complex, was a great selling point for the 
mockist
way of thinking to me.

Original comment by david.s...@gmail.com on 1 Aug 2007 at 5:36

[GoogleCodeExporter]

What a cunning idea!  I'll look into that.

I've actually checked in some introspection code, but I'll see if describeTo 
can be
reused in this way.

I'm a little wary because describeTo has not, so far, been intended to produce a
predictable sequence of calls to the description.  It's meant to be human 
readable
and, in my experience, human interface things go through a lot of churn.  Maybe 
we
should distinguish between descriptions and representations, like Python, where
representations would be stable and intended for machine processing.

Original comment by nat.pr...@gmail.com on 1 Aug 2007 at 5:42

[GoogleCodeExporter]

I'll retract this.  I don't need it any more and I couldn't work out an elegant 
way
of doing it.  I've deleted the implementation from SVN.

Original comment by nat.pr...@gmail.com on 12 Oct 2007 at 4:29

• Changed state: WontFix