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 EBD0E2F592 for ; Sat, 8 Jun 2019 15:52:03 -0400 (EDT) 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 QCUPXiNe3afi for ; Sat, 8 Jun 2019 15:52:03 -0400 (EDT) Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (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 43AB32FCCD for ; Sat, 8 Jun 2019 15:52:03 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH 5/5] swim: expose Lua triggers on member update References: <12b8ea76f7c1cd100a80ddcea3c29d20354e073e.1559433539.git.v.shpilevoy@tarantool.org> <20190608142753.GJ31327@atlas> From: Vladislav Shpilevoy Message-ID: Date: Sat, 8 Jun 2019 21:52:06 +0200 MIME-Version: 1.0 In-Reply-To: <20190608142753.GJ31327@atlas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Konstantin Osipov Cc: tarantool-patches@freelists.org On 08/06/2019 17:27, Konstantin Osipov wrote: > * Vladislav Shpilevoy [19/06/03 14:33]: >> >> Events object has methods to help a user to determine what update >> has happened. >> ```Lua >> local function on_update(member, events, ctx) >> if events:is_new() then > > This doesn't look proper English to me, events is plural, is_new() > is used for singular case. It is either an event_mask, or an event > list/set, but not something in the middle. Yes, probably you are right. I thing, 'eventset' or even just 'event' are good. See below why I avoid integers, masks, etc in public API. > > What about: > > event_mask:has(...)? >> + enum swim_ev_mask { >> + SWIM_EV_NEW = 0b00000001, >> + SWIM_EV_NEW_STATUS = 0b00000010, >> + SWIM_EV_NEW_URI = 0b00000100, >> + SWIM_EV_NEW_INCARNATION = 0b00001000, >> + SWIM_EV_NEW_PAYLOAD = 0b00010000, >> + SWIM_EV_UPDATE = 0b00011110, >> + SWIM_EV_DROP = 0b00100000, >> + }; > > Or simply export these objects to Lua and let users play with > them. > This is exactly what I was trying to avoid with all these mask metamethods. I want to be able in future to add old values of updated member attributes, if it will be necessary. It will be easy without breaking the old code, if from now we will return just an abstract 'events' object with some metamethods. Also probably in future we will not return the events as a mask. So I don't want to expose swim_ev_mask to Lua API. I've fixed the documentation with 'events' -> 'event' rename. Just treat the object as a complex event from multiple parts.