From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (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 96E0944643B for ; Fri, 2 Oct 2020 15:25:06 +0300 (MSK) From: "Timur Safin" References: <578d97ed-92a0-0154-a244-f94c36f32873@tarantool.org> <20200929050340.hwglcb2s4yyadcjr@tkn_work_nb> <20201001030538.iar7bimdtm63j7rc@tkn_work_nb> In-Reply-To: <20201001030538.iar7bimdtm63j7rc@tkn_work_nb> Date: Fri, 2 Oct 2020 15:25:05 +0300 Message-ID: <09e401d698b7$0f828f20$2e87ad60$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Content-Language: ru Subject: Re: [Tarantool-patches] [PATCH 2.X 2/7] module api: export box_key_def_dup List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Alexander Turenko' , 'Vladislav Shpilevoy' Cc: tarantool-patches@dev.tarantool.org : From: Alexander Turenko : Subject: Re: [Tarantool-patches] [PATCH 2.X 2/7] module api: export : box_key_def_dup : : On Wed, Sep 30, 2020 at 01:19:19AM +0200, Vladislav Shpilevoy wrote: : > On 29.09.2020 07:03, Alexander Turenko wrote: : > > On Tue, Sep 29, 2020 at 12:21:02AM +0200, Vladislav Shpilevoy wrote: : > >> Thanks for the patch! : > >> : > >> See 2 comments below. : > >> : > >> On 24.09.2020 19:00, Timur Safin wrote: : > >>> Exporting `box_key_def_dup` as accessor to the internal : `key_def_dup` : > >> : > >> 1. Do you really need this method? It looks like it can be done by : > >> : > >> old_parts = box_key_def_dump_parts(old_key_def); : > >> new_key_def = box_key_def_new_ex(old_parts); : > >> : > >> So the method seems redundant. : > > : > > It is not strictly necessary, however using of box_key_def_dup() would : > > be less error-prone (no extra allocations) and the resulting code : would : > > be more readable. My vote is for this method if you have no strict : > > objections. : > : > Regarding this one I am not strictly against, but I don't like : overloading : > module API with too many methods, especially with the trivial ones, : which : > can be easily implemented via the others in a few lines. : : I'll not strictly against if Timur will decide to going this way, but : personally I would not be very comfortable with copying over : serialization-deserialization if I would be author of the external : module. Thanks Sasha! Honestly I didn't expect **this** function to be discussed at all, because it was simple convenience wrapper around function existing in both 1.10 and 2.*. So I'd rather prefer to keep it as part of module api. Timur