From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 16 Jan 2019 14:40:12 +0300 From: Alexander Turenko Subject: Re: [PATCH v2 2/6] Add functions to ease using Lua iterators from C Message-ID: <20190116114012.gxw4q3nxj7moopx6@tkn_work_nb> References: <2c8049118f86934d6088636dba44f92f381ef8ff.1547064388.git.alexander.turenko@tarantool.org> <20190110122909.novsa6o6duykot6a@esperanza> <20190115232623.huxpqj4adoqqi3mo@tkn_work_nb> <20190116081802.wpnbjaagm7qftlnb@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190116081802.wpnbjaagm7qftlnb@esperanza> To: Vladimir Davydov Cc: tarantool-patches@freelists.org List-ID: > > > > + > > > > +/** > > > > + * Create a Lua iterator from {gen, param, state}. > > > > > > May be, we could pass idx == 0 to create an iterator from > > > gen, param, state (without a table)? Would it be worthwhile? > > > > > > > I think it is good idea, because cases could be different. My thought > > was that we'll add another function for this case (if we'll need), but > > using idx == 0 is better. I created the similar API before for > > luaT_newtuple(). > > > > And I think the new merger API will require it. > > The patch looks good to me now, but I'm still not sure the new merger > implementation will need to deal with Lua iterators in C at all, as one > can easily write a wrapper function in Lua turning an iterator to a > 'fetch' closure, which then can be passed to a source constructor. This is not the thread about merger, but the idea looks weird for me. 'next' has one meaning (get one tuple), 'fetch' has another meaning (get next tuples batch). 'next' is written in C and predefined, 'fetch' is user-defined Lua function. When you'll try to express one over another you'll find rough edges, e. g. need of extra wrapping table. But my main objection is that it is hard to think what is going on when 'next' and 'fetch' are mixed. WBR, Alexander Turenko.