Evgeniy,
Thanks for the answer, see my thoughts below.
On 30.06.26, Evgeniy Temirgaleev wrote:
> Hi, Sergey!
>
> LGTM. And please see my note about renaming issue.
>
> >
> > From: Sergey Kaplun <
skaplun@tarantool.org>
> > To: Evgeniy Temirgaleev <
e.temirgaleev@tarantool.org>
> > Cc: tarantool-patches@dev.tarantool.org, Sergey Bronnikov <
sergeyb@tarantool.org> > >
> > Date: Monday, June 29, 2026 10:21 PM +03:00
<snipped>
> > > > +
> > > > +def ctype_isrefarray(info):
> > > > + return (info & (CTMASK_NUM | CTF_VECTOR | CTF_COMPLEX)) == \
> > > > + ctinfo(CT_ARRAY, 0)
> > > > +
> > > > +
> > > > +def ctype_cid(info):
> > > >
> > >
> > > Let’s put these function definitions in the ‘lj_ctype.h’ order?
> > > May we group the definitions by corresponding C files also? # lj_ctype.h
> > … # lj_cdata.h … # lj_xxx.c …
> >
> >
> > Sorted as you suggested. The sorting is the following:
> > * lj_ctype.h
> > * lj_cdata.h -- `cdata_getptr()`
> > * lj_obj.h -- `cdataptr()`
> >
>
> Thanks! We can add a comment with file name before each block to improve readability slightly more. Feel free to ignore.
I suppose that ctags or whatsoever will do the trick. Ignoring since you
don't insist.
<snipped>
> > > >
> > >
> > > Also, it seems, it will be easy to read to code, if it will be possible
> > to distinguish between ported functions and extension itself ones. May be
> > by use the ‘dbg_’ prefix for extension function names.
> >
> > I suppose this refactoring can be done in the separate issue. Since it
> > is related to all functions. Also, the `dbg` is already used for the
> > instance of the corresponding class. `dump_` prefix looks common for all
> > dumpers of our extension.
> >
>
> Agreed. And I vote for this patch.
> May be it will be several documented prefixes. It will be more verbosely, but I think it will be very helpful in a long perspective for supporting the extension to quick distinguish LuaJIT-ported routine e.g. `ctype_preplit` with extension routine e.g. `cdata_val_int64`.
> Can you offer some prefix name good for you now? May be we can start naming with it at this point, what do you think?
For now we have several "prefixes":
* `dbg.` for the debugger implementation defined helpers.
* `dump_` for the dumper function of any kind (even helpers).
* `LJ*` for the classes to be the entry points for our extensions.
I'm not sure that ctype_preplit -> dump_ctype_preplit helps for find the
original logic for this dumper from the LuaJIT source code. So, I'm open
to ideas ;).
I prefer if the refactoring of names will be done separately so there
is no a part of the naming in this patch series and another part in the
next one. At least this is inconsistent.
<snipped>
>
> --
> Best regards,
> Evgeniy Temirgaleev
--
Best regards,
Sergey Kaplun