Re: [Tarantool-patches] [PATCH v12 3/8] module_cache: improve naming

[Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

On Sat, Jan 30, 2021 at 07:53:03PM +0100, Vladislav Shpilevoy wrote:
> Hi!
> 
> On 24.01.2021 23:32, Cyrill Gorcunov wrote:
> > On Sun, Jan 24, 2021 at 05:27:12PM +0100, Vladislav Shpilevoy wrote:
> >> Thanks for the patch!
> >>
> >> Very dubious commit. To me the old and new names look the same.
> >> 'func_name' was even better than 'func_name_desc'. At least
> >> because it was shorter, and 'desc' does not add any more meaning.
> >>
> >> On 18.01.2021 21:35, Cyrill Gorcunov via Tarantool-patches wrote:
> >>>  - rename func_name to func_name_desc because
> >>>    it is not just a name but rather a name descriptor
> >>>    which includes symbol address
> >>
> >> I don't see any address in it. Only name tokens.
> > 
> > struct func_name_desc {
> > 	/**
> > 	 * Null-terminated symbol name, e.g.
> > 	 * "func" for "mod.submod.func".
> > 	 */
> > --->	const char *sym;
> > 	/**
> > 	 * Package name, e.g. "mod.submod" for
> > 	 * "mod.submod.func".
> > 	 */
> > 	const char *package;
> > 	/**
> > 	 * A pointer to the last character in ->package + 1.
> > 	 */
> > 	const char *package_end;
> > };
> > 
> > I marked the address.
> 
> You said "symbol address". But it is not a symbol address. It is
> an address pointing at a part of the name string. Not at the
> actual symbol, which you need to load later.

This is an address of part of the string which represents symbol.
When symbol is loaded it will have "resolved" address. Plain
address and resolved address are pretty different things in
loaders terminology. In real loaders initial address is position
inside strings section which you're resolving later upon symbols
lookup. We have the similar approach, except our initial address is
position inside package string...

> 
> > The structure is not a function name
> > but consists of two parts - package path and function name
> > itself and maybe something new will be added in future.
> 
> In this case 'name desc' is also invalid - it does not describe
> the name. Because there is also a path which is not a part of
> the name.
> 
> It would be more correct to call it func_path then.

It is not a path. It is a *descriptor* which identify function
in unique way on a storage device. But sure I will do

struct func_path {
	const char *sym_name;
	const char *package;
	const char *package_end;
};

> 
> > So func_name is suitable for plain names but not for strings
> > where some part of it has a special meaning with hidden
> > extension inside, hereby a descriptor.
> 
> In this case you didn't really change it - it was about function
> name and stayed about function name. It should be func_path then.
> If you really want to rename.

OK, I would prefer to rename. func_name already used in many places
with rather plain string context, and forcing to use some fulltext
search is not a good idea. To be honest I would keep func_name_desc
here because the structure might extend in future but func_path
fine as well.

> 
> > And don't forget
> > about grepability, without this name change grep returns
> > a number of irrelevant results.
> 
> This struct is defined and used in a single file. It is not that
> hard to find it here. Especially if you use some smarter tools.
> For instance, I use full text search in Sublime, and have never had
> any issues with finding anything in Tarantool sources. Plus for
> structs and functions you usually want to use ctags (Sublime also
> generates these tags). Maybe it is only hard when you use command
> line and bare grep.