Import matchers + a workaround to __or__ problem

[Rodrigo Manhães]

Hi all,

Some time ago, I talked to Hugo Lopes about a change to Should-DSL
that forces matchers to be imported. It is implemented, as usual, in a
branch on my fork [1]. However, the frame hack stuff could not be
entirely removed because there's no sense in importing predicate
matchers, once they cannot exist until the moment of expectation
execution and keeping their existence after the expectation would be a
complete nonsense. So, I don't know if forcing regular, aliases, and
custom matchers to be imported, but not the predicate ones, is a
desirable feature.

About the __or__ problem (see [2]), I've implemented a
feature-disguised workaround (in another branch on my fork [3], of
course), consisting of a function named _ (underscore), that will
enclose the object. In the doctest [4], I suggest using it in the form
"from should_dsl import _ as this", where "this" is a word that is
suitable depending on the context of the test.

I think these are the last issues to the 2.0 final release! Please
send your comments!

[1] https://github.com/rodrigomanhaes/should-dsl/tree/matchers-must-be-imported
[2] https://github.com/hugobr/should-dsl/issues/12
[3] https://github.com/rodrigomanhaes/should-dsl/tree/left_enclosing
[4] https://github.com/rodrigomanhaes/should-dsl/blob/left_enclosing/should_dsl/doctests/left_enclosing.txt

Cheers,
-------
Rodrigo Manhães
-------
https://github.com/rodrigomanhaes
http://programacaoradical.blogspot.com
http://lattes.cnpq.br/9851240805895558

[Hugo Lopes Tavares]

Should-DSL is now owned by nsi-iff github organization ;-)

Cheers,
Hugo.

[Rodrigo Manhães]

Hi all,

I've pushed another branch [1], dropping support to predicate matchers.

This branch was forked from another [2], in which all the matchers
should be imported. These two changes allowed the remotion of all
frame hacks from the Should-DSL code.

[1] https://github.com/rodrigomanhaes/should-dsl/tree/remove-predicate-matchers
[2] https://github.com/rodrigomanhaes/should-dsl/tree/matchers-must-be-imported

Cheers,
-------
Rodrigo Manhães
-------
https://github.com/rodrigomanhaes
http://programacaoradical.blogspot.com
http://lattes.cnpq.br/9851240805895558

2011/9/4 Rodrigo Manhães <rman...@gmail.com>:

[Hugo Lopes Tavares]

On Fri, Oct 28, 2011 at 6:19 PM, Rodrigo Manhães <rman...@gmail.com> wrote:
> Hi all,
>
> I've pushed another branch [1], dropping support to predicate matchers.

Hi Rodrigo,

Predicate matchers are not so easy to grasp, and this change is a big
one. Are you thinking everyone who needs a predicate matcher should
implement their own from scratch?

[]s

[Rodrigo Manhães]

2011/10/28 Hugo Lopes Tavares <hlt...@gmail.com>:
> Hi Rodrigo,

Hi!

>
> Predicate matchers are not so easy to grasp, and this change is a big
> one. Are you thinking everyone who needs a predicate matcher should
> implement their own from scratch?

In one word, yes (but, remember, this is only a proposal).

The goal is remove all frame hacks from the code, and I don't know how
to remove them and keep predicate matchers working. Regular matchers
can be imported; predicate matchers not, since they only make sense in
the exact moment when the expectation is running.

I like predicate matchers, but I don't know a way to implement them
without hacks.

Do you have any idea about this?

[Hugo Lopes Tavares]

I don't know too :\

Keep removing those hacks, and it should be easy to create a new
predicate matcher by yourself..

Later!