[tarantool-patches] [PATCH v2 4/8] lua: rework luaL_field types to support msgpack extensions

[Serge Petrenko]

> 13 авг. 2019 г., в 0:23, Konstantin Osipov <kostja at tarantool.org> написал(а):
> 
> * Serge Petrenko <sergepetrenko at tarantool.org> [19/08/08 15:01]:
> 
>> We are planning to add new types, such as decimal, which will all
>> share a single msgpack type - MP_EXT. MP_EXT is currently treated as
>> uninterpretable in encoders. So, in order to distinguish such new types
>> introduce MP_FIELD_* instead of MP_* types for use in luaL_field
>> structure and msgpack encoders.
>> New MP_FIELD_* types will correspond to MP_* types, MP_FIELD_UNKNOWN
>> will serve the same purpose, as MP_EXT does now, and various MP_FIELD_*
>> types will correspond to various MP_EXT subtypes, such as MP_DECIMAL in
>> future.
> 
> uhg, so there is enum field_type, there is enum mp_type, and these
> are not enough, let's have a yet another enum...
> 
> Sounds like you should be able to get by with enum field_type and
> enum mp_type, no?
> 

Sorry for the confusion. I guess mp_field_type is just a bad name.
It has nothing to do with enum field_type. It just represents all the
messagepack types, including the extension types.
It helps to eliminate a switch for extension type every time we get an
MP_EXT. So, it only deals with mp_type and mp_user_type.

> Look at mp_type when you can, and when you get MP_EXT or is
> otherwise confused, look at field_type?

That’s what I’ve done in previous revision, but Vladimir didn’t like it.
And having implemented both variants, I agree that this enum simplifies
the code quite a lot. This is especially noticeable with patch 6.

So, my proposal is to change the name to something better.
value_type? mp_value_type maybe?

> 
> -- 
> Konstantin Osipov, Moscow, Russia
> 

--
Serge Petrenko
sergepetrenko at tarantool.org