[tarantool-patches] Re: [PATCH v5 4/9] lib: introduce json_path_cmp routine

[Konstantin Osipov <kostja@tarantool.org>]

* Vladimir Davydov <vdavydov.dev@gmail.com> [18/12/03 21:51]:
> On Mon, Dec 03, 2018 at 08:37:41PM +0300, Konstantin Osipov wrote:
> > * Vladimir Davydov <vdavydov.dev@gmail.com> [18/11/30 17:01]:
> > > > + * Compare two JSON paths using Lexer class.
> > > > + * - @a path must be valid
> > > > + * - at the case of paths that have same token-sequence prefix,
> > > > + *   the path having more tokens is assumed to be greater
> > > > + * - when @b path contains an error, the path "a" is assumed to
> > > > + *   be greater
> > > > + */
> > > > +int
> > > > +json_path_cmp(const char *a, uint32_t a_len, const char *b, uint32_t b_len);
> > > > +
> > > 
> > > One typically expects cmp(a, b) to be equivalent to -cmp(b, a).
> > > Can't we make json_path_cmp satisfy this property, for example, by
> > > requiring both strings to be valid json paths with an assertion?
> > 
> > Why bother?
> 
> To simplify the function protocol. Currently, it's kinda lopsided: path
> 'a' must be valid, which is checked by an assertion, while path 'b' may
> not be valid, in which case special comparison rules are applied. I find
> such an asymmetry rather unnatural for a comparison function. I'd prefer
> if we either allowed both paths to be invalid or required them both to
> be valid.

I agree but perhaps we could change the function logic instead, there
would be an extra comparison in the bad cases when our assumption
about which path is valid turned to be wrong. I haven't checked if
it is really possible though.

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov