From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 13 Aug 2019 00:23:29 +0300 From: Konstantin Osipov Subject: Re: [PATCH v2 4/8] lua: rework luaL_field types to support msgpack extensions Message-ID: <20190812212329.GF32337@atlas> References: <8732ff5bc9cfe6622a14e773a76053ee1a20fcf8.1565263272.git.sergepetrenko@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8732ff5bc9cfe6622a14e773a76053ee1a20fcf8.1565263272.git.sergepetrenko@tarantool.org> To: Serge Petrenko Cc: vdavydov.dev@gmail.com, tarantool-patches@freelists.org List-ID: * Serge Petrenko [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? Look at mp_type when you can, and when you get MP_EXT or is otherwise confused, look at field_type? -- Konstantin Osipov, Moscow, Russia