-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make schema matching easier #18
Comments
That looks pretty awesome to me. I like the What do you think about replacing |
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! On Mon, Aug 5, 2013 at 12:50 PM, Paul Annesley notifications@github.com
|
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
The text was updated successfully, but these errors were encountered: