Open chancancode opened 11 years ago
That looks pretty awesome to me.
I like the #fuzzy
, #repeated
etc methods, too.
What do you think about replacing anything
and nothing
with match.anything
and match.nothing
, so that only match
needs to be included into the RSpec/whatever namespace?
Haven't considered that one, I like the suggestion! In that case the signature of match would have to be def match(*args) ... end to properly distinguish between match(nil) vs match(), which presumably returns a DSLProxy object or something similar which lets you call anything/nothing etc on it.
I need to think a little but more about the drawbacks of returning proxy objects in general, eg how to report "dangling proxy objects" errors, etc. But I am pretty sure those could be worked out.
Thanks for the feedback! — Sent from Mailbox for iPhone
On Mon, Aug 5, 2013 at 12:50 PM, Paul Annesley notifications@github.com wrote:
That looks pretty awesome to me. I like the
#fuzzy
,#repeated
etc methods, too.What do you think about replacing
anything
andnothing
withmatch.anything
andmatch.nothing
, so that onlymatch
needs to be included into the RSpec/whatever namespace?Reply to this email directly or view it on GitHub: https://github.com/chancancode/json_expressions/issues/18#issuecomment-22136072
Is this happening?
Proposed API:
match
(perhaps need a better name, not sure if this conflicts with other gems) is a factory method that always returns aJsonExpressions::Matcher
. Passing aJsonExpressions::Matcher
tomatch
is a no-op, otherwise it would wrap that with the appropriate subclass ofJsonExpression::Matcher
.JsonExpressions::Matcher
defines#and
,#or
which does what you would expectJsonExpressions::Matcher
also defines#repeated
which takes an integer or a integer range which turns its receiver into aJsonExpression::RepetitionMatcher
and does what you would expectanything
returns an instance ofJsonExpressions::WildcardMatcher
which matches anything (including nil), which is basicallynothing
returns an instance of `JsonExpression::NothingMatcher, which asserts that key doesn't existsmatch
,JsonExpressions::Matcher#and
andJsonExpressions::Matcher#or
with no arguments returns aJsonExpressions::NotProxy
which defines a#not
method, and that wraps its argument in aJsonExpressions::NotMatcher
which negates its results, and then passes this to the original receiver + methodJsonExpression::ArrayMatcher
,JsonExpression::ObjectMatcher
defines#fuzzy
,#exact
,#ordered
and#unordered
, so no more monkey-patchingArray
andHash
Would like some feedback on this, especially on the naming (fuzzy/exact vs forgiving/strict, etc) and any use cases that I missed.
*Also, please let me know if you expect the
match
method to conflict with a library you are using today. I'm also open to other suggestions for the top level method that we expose/inject (pattern
,expression
,expr
?)No ETA. This is probably gonna take some time and tbh it won't be on the top of my priority list for the next while, but I'll do what I can. But now that the spec is here, if you really want it now you can always implement this spec yourself :) (If you do, please pick a different name to avoid confusion)
Thank you for sticking around after I ignored you pull request for so long! (To be clear, I did not abandon the gem – I've been actively using it on Rails 4 / Ruby 2.0 myself, and I'll fix any bugs that prevents it from working correctly, I just haven't been needing these schema oriented functionalities.)
/cc @pda @tdumitrescu @martinstreicher @iangreenleaf @matthew-bb @sricc