Matcher parameterizing: method chaining or named parameters?
Rodrigo Manhães
I've created a micro-DSL for the matcher be_like [1] and I want to
bring it to discussion.
An issue [2] requested to matcher be_like accept flags for regex
matching. My first implementation, pushed to mainline, was very
simple:
>>> import re
>>> 'Hello\nWorld' |should| be_like(r'hello.+', re.IGNORECASE + re.DOTALL)
This works, but forces the test code to import the regex module (re).
Yesterday I've created an alternative implementation (the "micro-DSL"
I wrote above), that provides the following:
>>> 'Hello\nWorld' |should| be_like(r'Hello.+').dotall().ignore_case()
Another issue, opened yesterday [3], requested the matcher "include"
to be able to compare strings ignoring case. Proposed solution, in the
same way to applied on be_like is:
>>> 'Hey ya' |should| include('hey').ignoring_case()
All ok, right?
However, other matchers have been using named parameters for matcher
parameterizing, e.g.:
>>> 1 |should| close_to(0.9, delta=0.1)
>>> foo |should| throw(TypeError, message="We have a problem!")
We have chosen the form above and not the following:
>>> 1 |should| close_to(0.9).with_delta(0.1)
>>> foo |should| throw(TypeError).with_message("We have a problem!")
but we never thought about it (well, *I* never thought...). There's no
problem in supporting the two styles. However, I think maybe it's not
good we have two ways of making things (it's nice to keep our DSL
simple, right?).
I think we should carefully monitor the evolution of Should-DSL, lest
it fall into chaos. A kind of "linguistic chaos" was, imho, the main
reason for the changes introduced in version 2.0. Or am I
overreacting?
Opinions?
[]'s
Rodrigo
[1] Currently, it's in a branch until we discuss the alternatives:
http://github.com/rodrigomanhaes/should-dsl/tree/be_like-dsl
[2] http://github.com/hugobr/should-dsl/issues/closed#issue/3
[3] http://github.com/hugobr/should-dsl/issues#issue/4
Hugo Maia
really nice and clean (Congrats, by the way). I think too that maybe it's not good we have two
ways of making things, that it's nice to keep our DSL simple.
[ ]'s
--
Hugo Maia Vieira
http://hugomaiavieira.com
@hugomaiavieira
Rodrigo Manhães
> Well, I full agree with all Rodrigo's points. The the "micro-DSL"
> alternative implementation is
> really nice and clean (Congrats, by the way). I think too that maybe it's
> not good we have two
> ways of making things, that it's nice to keep our DSL simple.
Cool!
But what to do with the preexisting matchers that uses named
parameters as information passing? Should we convert it all to method
chaining?
[]'s
Rodrigo
Hugo Maia
parameters as information passing? Should we convert it all to method
chaining?
Hugo Lopes Tavares
will not use any flags.
And I don't think that micro-dsl would become mainstream, because IMHO
that's enough for DSLs. Some cases the best is no dsl.
The named parameter thing is a good one to pick. I am +1 on that.
>>> 'My name is Earl' |should| include('EARL', ignoring_case=True)
>>> import re
>>> 'My name is Earl' |should| be_like(r'^my name is .+$', flags=re.IGNORECASE)
[]s
PS.: Rodrigo, re flags (like many other kinds of flags) are grouped
using pipes (|), because it is related to the bitwise stuff. That
works, but is not the usual.
Rodrigo Manhães
> I don't see any problem with the import, and in most cases, people
> will not use any flags.
> And I don't think that micro-dsl would become mainstream, because IMHO
> that's enough for DSLs. Some cases the best is no dsl.
Ok, I'll keep it as is.
> PS.: Rodrigo, re flags (like many other kinds of flags) are grouped
> using pipes (|), because it is related to the bitwise stuff. That
> works, but is not the usual.
I agree. For this case, both bitwise-or and addition produce the same
result, but "|" is more intention-revealing.
[]'s
Rodrigo