Hi --
I said:
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 ]
I wonder whether one could combine this with tests for class ancestry,
by matching a class/module name (#is_a?) and, at the same time,
verifying that the object's capabilities are a match for its ancestry.
Or something. I haven't puzzled it through very deeply.
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...
I'd tend to say: if it's the type, it's not the class, and if you have
to explicitly request it, it's not duck-typing
But yes, I think
there are occasions for all these things, in various combinations.
As others have often pointed out, respond_to? != duck typing, but I do
tend to think of respond_to?-based logic as a kind of "weak duck
typing", if that isn't too arcane. It falls short of the true "Here,
do this!" spirit of true duck typing, but undeniably (in my view) has
a foot in the same camp, in that it factors in the dynamism of type.
David
