> I'm not sure about Christian, but I think itsme213 meant
> sort of the opposite: how does your system relate to the
> duck-typing environment of Ruby, where type != class
> (i.e., an object's capabilities and its class's instance
> methods are not necessarily the same thing)?  Are you
> thinking of extending the system so that it could match,
> for example,  "an array of objects that respond to '[]'"

Oh! Ok, well that's easy, it would be something like:

+[ proceq{|x| x.respond_to? :[] }+1 ]

Being forced to use a proceq (gawd that's a terrible name) here is a
little ugly. Eventually, I want to be able to pass arguments to
property matchers, so the above could be:

+[ -{ [:respond_to?, :[]]=>true }+1 ]

> duck typing per se, as I understand it, really means just
> requesting action from objects without a lot of preliminary
> querying and measuring (whether it be is_a?, respond_to?,
>  or whatever).  

If you're doing something complicated, you occasionally have to
explicity request the type (whether duck- or class-) of objects you're
working with, in order to do the right thing with it. I know this isn't
polymorphic, but sometimes it is the right way...