From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 13 Aug 2019 00:28:00 +0300 From: Konstantin Osipov Subject: Re: [PATCH v2 5/8] box: rework field_def and tuple_compare to work with mp_field_type instead of mp_type Message-ID: <20190812212800.GG32337@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: To: Serge Petrenko Cc: vdavydov.dev@gmail.com, tarantool-patches@freelists.org List-ID: * Serge Petrenko [19/08/08 15:01]: > This a preparation for adding decimal fields and decimal comparators. It > will be needed, since newly introduced user types, such as decimal, will > all share a single mp_type, and we want to avoid additional checks for > MP_EXT subtypes. I think this is confusing as hell. This new enum doesn't represent anything, it's neither field_type (otherwise it would be enum field_type) nor mp_type. Sounds like it is a strange "weight" or "code point" calculated for a Cartesian product of field_type, mp_type and mp_ext type. Well, if you want to optimize the code to look at this code point, let's at least make it clear that it's not a type, but an optimization technique we use. Or let's just look at a combination of field_type and mp_type and not introduce this strange entity just to preserve a few switches around. -- Konstantin Osipov, Moscow, Russia