From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 4 Apr 2019 17:42:03 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH v2 2/2] lua: add key_def lua module Message-ID: <20190404144203.6kwt63nyli2pdowe@esperanza> References: <20190328020146.lluz4mg5tacpghwv@tkn_work_nb> <35ed4661-9789-7cf1-6627-2ced2a821939@tarantool.org> <6d915212-e80f-4a6d-d884-b838bf25f8a7@tarantool.org> <20190328112158.kpxsk6b55noicbes@tkn_work_nb> <20190403111003.x7vq7olda55tthgi@esperanza> <20190404050733.2xuobbezfzbs47l4@tkn_work_nb> <20190404083823.adyv5zxrlgobfro2@esperanza> <20190404111743.i32fsgmin3uugi5g@tkn_work_nb> <20190404120040.pcsnns3l4aw32abv@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190404120040.pcsnns3l4aw32abv@tkn_work_nb> To: Alexander Turenko Cc: Kirill Shcherbatov , tarantool-patches@freelists.org List-ID: On Thu, Apr 04, 2019 at 03:00:40PM +0300, Alexander Turenko wrote: > > > > > Also, returning 1, 0, -1 to Lua looks uncommon. May be, we'd better > > > > > introduce 'equal', 'greater', 'less', etc helpers returning bool? > > > > > > > > A function for table.sort(table, func) returns boolean, so it make > > > > sense. I'm a bit afraid that we'll need to make two calls: say, :less() > > > > and :equal() to determine an order of tuples strictly. But I cannot > > > > provide a case where it can be necessary. Are you know one? > > > > > > No, I don't write much code in Lua. > > > > > > However, if we decided to switch to bool return parameter, I'd implement > > > all possible combinations, i.e. eq, ge, le, gt, lt. > > > > I mean are there cases when we need to check, say t1 < t2 and if it is > > false then check whether t1 == t2 or t1 > t2? In other words, cases when > > we need to distinguish all three possible situations. Some algorithms? > > > > I looked throught [1] and it seems it does not contain any reason why > > <=> operator was added to C++20 except ones related to comparison > > operations autogeneration. > > > > We can just add :cmp() in addition to all other variants, what do you > > think? > > > > We can also do the trick: return {eq = } from :le() / :ge() > > instead of true, but this way looks weird. > > > > [1]: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0515r0.pdf > > One example that looks valid: search in a binary search tree, where > non-leaf nodes hold elements. Okay, I see, it means that someone might actually need cmp(), not eq/le/etc, in which case adding all those methods returning bool doesn't look like a good idea. I tend to think that the API proposed originally was okay, after all. Let's send an RFC to dev@ and see what others think.