From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 623F92D6DF for ; Mon, 3 Dec 2018 15:14:42 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qynJc3TCmEPb for ; Mon, 3 Dec 2018 15:14:42 -0500 (EST) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 9DD602D63C for ; Mon, 3 Dec 2018 15:14:41 -0500 (EST) Date: Mon, 3 Dec 2018 23:14:37 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v5 4/9] lib: introduce json_path_cmp routine Message-ID: <20181203201437.GG2890@chai> References: <20181130104601.4mal76geccq7q6ho@esperanza> <20181203173741.GF2890@chai> <20181203184827.jcmxwhuyjhfnbbt2@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181203184827.jcmxwhuyjhfnbbt2@esperanza> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: Kirill Shcherbatov * Vladimir Davydov [18/12/03 21:51]: > On Mon, Dec 03, 2018 at 08:37:41PM +0300, Konstantin Osipov wrote: > > * Vladimir Davydov [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