[tarantool-patches] Re: [PATCH 5/5] swim: expose Lua triggers on member update

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

On 08/06/2019 17:27, Konstantin Osipov wrote:
> * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [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.