From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 dev.tarantool.org (Postfix) with ESMTPS id 9B7E7469719 for ; Tue, 17 Nov 2020 12:11:17 +0300 (MSK) Date: Tue, 17 Nov 2020 12:11:14 +0300 From: Igor Munkin Message-ID: <20201117091114.GA14086@tarantool.org> References: <20201111200408.49148-1-olegrok@tarantool.org> <1b1c65f6-2ac5-0112-a5b9-ffa8f94b1b71@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1b1c65f6-2ac5-0112-a5b9-ffa8f94b1b71@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] lua: introduce function for uuid comparison List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Vlad, I glanced the patch and your review and want to clarify one point. On 16.11.20, Vladislav Shpilevoy wrote: > Hi! Thanks for the patch! > > Lets change subsystem from 'lua:' to 'uuid:'. The former is too > general. > > See 4 comments below. > > On 11.11.2020 21:04, olegrok@tarantool.org wrote: > > From: Oleg Babin > > > > Since Tarantool has uuid data type sometimes we want to compare > > uuid vaues as it's possible for primitive types and decimals. This > > patch exports function for uuid comparison and implements le and > > lt metamethods for uuid type. > > To be consistent with decimal type this patch allows to compare > > uuid with uuid string representation. > > > > @TarantoolBot document Title: uuid compare > > > 4. Hmmmmm > > tarantool> u1 = 'b0b681e9-dd43-4341-98b4-a973b23f1421' > --- > ... > > tarantool> u2 = uuid() > --- > ... > > tarantool> type(u2) > --- > - cdata > ... > > tarantool> type(u1) > --- > - string > ... > > tarantool> u2 < u1 > --- > - true > ... > > tarantool> u1 > u2 > --- > - true > ... > > Doesn't this look wrong? Yes and no. At first result is the same. The issue you mentioned above relates to cdata comparison, but this is wrong in general. According to Lua Reference manual[1] the objects can be compared via the metamethods iff they are the same types. Otherwise the comparison fails. Consider the following example: | $ tarantool | Tarantool 1.10.8-0-g2f18757 | type 'help' for interactive help | tarantool> a = setmetatable({ a = 'QQ' }, { __lt = function(self, obj) if type(obj) ~= 'string' then error('invalid') end return self.a < obj end }) | --- | ... | | tarantool> str = 'QKRQ' | --- | ... | | tarantool> a < str | --- | - error: '[string "return a < str"]:1: attempt to compare table with string' | ... Anyway, cdata comparison is badly described on LuaJIT FFI semantics page[2], but at least there is the following note: | Comparisons for equality/inequality never raise an error. Even | incompatible pointers can be compared for equality by address. Any | other incompatible comparison (also with non-cdata objects) treats the | two sides as unequal. At the same time, Mike implemented kinda __rlt for cdata types. In other words, if the left operand is not cdata, but the right one is, then it would lookup the right one for __lt. I failed to find the place this freaking hack is described but this is how it works. > > From what I see here: http://lua-users.org/wiki/MetamethodsTutorial > they say, that for '<' Lua uses metatable of the left object. It means, > that if string is on the left, it will use string metamethods. Although > I may be wrong, and you need to check how it actually works. If it is > true, I am afraid we can't support string vs cdata-uuid comparison. Looks like we can, *but* I only checked your example, so I see no other pitfalls for now. Anyway, I guess I will make a precise description for the way cdata metamethod are looked up. > Only cdata-uuid vs cdata-uuid. For string case you may need to add a new > function. Probably in your own application. [1]: https://www.lua.org/manual/5.1/manual.html#2.8 [2]: http://luajit.org/ext_ffi_semantics.html -- Best regards, IM