From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Mon, 3 Dec 2018 21:48:27 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [tarantool-patches] Re: [PATCH v5 4/9] lib: introduce
 json_path_cmp routine
Message-ID: <20181203184827.jcmxwhuyjhfnbbt2@esperanza>
References: <cover.1543229303.git.kshcherbatov@tarantool.org>
 <edf19388a098ecb3a547f403f56ca1a9c86a5f76.1543229303.git.kshcherbatov@tarantool.org>
 <20181130104601.4mal76geccq7q6ho@esperanza>
 <20181203173741.GF2890@chai>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181203173741.GF2890@chai>
To: Konstantin Osipov <kostja@tarantool.org>
Cc: tarantool-patches@freelists.org, Kirill Shcherbatov <kshcherbatov@tarantool.org>
List-ID: <tarantool-patches.dev.tarantool.org>

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.