About predicate matchers search

[Hugo Lopes Tavares]

Fellows,
Rodrigo has implemented "predicate matchers" in this upcoming release,
but the problem is that it looks for the exact method name. For
instance:

item |should| be_black

What does it do? Nowadays it looks for `black` method in `item`, and
check the return value. Some implementation would be:
>>> class Item(object):
... ....
... def black(self):
... return self._color == Color.BLACK

The problem is that it is common in ruby, where boolean methods use to
be `method_name?`, with question mark. But in python it is not that
common.

So I propose we should let people custom how the predicate matcher can
be, passing a regex. Like:
>>> from should_dsl import predicate_regexes
>>> predicate_regexes.append(r'^is_(?P<method_name>.*)$')

And by default we change the search for `is_<METHNAME>`, so we would
have something like the following:
>>> class Item(object):
... ....
... def is_black(self):
... return self._color == Color.BLACK

What you think?

[Rodrigo Manhães]

Hi all!

I think the current implementation is the most common for attributes,
and the "is_"-prefixed one is most common for methods, right? So, I'm
in favor to implement both, in a non-customizable fashion, at least
for now.

By the way, it would be useful implement support to aliases for
matcher names in the should-dsl "engine". With this feature, my
suggestion in last paragraph can be easily implemented. Regardless, I
think aliases support for custom matchers is a good feature to have.
What do you think?

[]'s
Rodrigo

2010/6/11 Hugo Lopes Tavares <hlt...@gmail.com>:

[Rodrigo Manhães]

Should-DSL's 2.0 release is approaching.

What about the changes on predicate matchers? Any ideas?

[]'s
Rodrigo

2010/6/12 Rodrigo Manhães <rman...@gmail.com>:

[Rodrigo Manhães]

About prefixes for boolean methods, Python have no standardization in
this matter. Examples are str class' isalpha, islower, isupper,
isdigit,... methods.

I agree that is very important we support pythonisms, but how many
"pythonisms" should we handle?

Options:
1) let the user configure (as hltbra proposed)
2) keep all as is (support only to exact method name)
3) support the three forms (exact method name, "is_"-prefixed and is-prefixed)

Option 3 would be easier if we implement support to define aliases for
matchers, that I think is a good feature by itself.

Well, give your ideas...

[]'s
Rodrigo

2010/6/15 Rodrigo Manhães <rman...@gmail.com>: