From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [tarantool-patches] [PATCH v2 4/8] lua: rework luaL_field types to support msgpack extensions From: Serge Petrenko In-Reply-To: <20190812212329.GF32337@atlas> Date: Tue, 13 Aug 2019 16:15:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8732ff5bc9cfe6622a14e773a76053ee1a20fcf8.1565263272.git.sergepetrenko@tarantool.org> <20190812212329.GF32337@atlas> To: Konstantin Osipov Cc: Vladimir Davydov , tarantool-patches@freelists.org List-ID: > 13 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3., =D0=B2 0:23, Konstantin Osipov = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):= >=20 > * Serge Petrenko [19/08/08 15:01]: >=20 >> 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. >=20 > uhg, so there is enum field_type, there is enum mp_type, and these > are not enough, let's have a yet another enum... >=20 > Sounds like you should be able to get by with enum field_type and > enum mp_type, no? >=20 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=E2=80=99s what I=E2=80=99ve done in previous revision, but Vladimir = didn=E2=80=99t 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? >=20 > --=20 > Konstantin Osipov, Moscow, Russia >=20 -- Serge Petrenko sergepetrenko@tarantool.org