[alsa-lib][PATCH 0/6] add API of equality and comparison for a pair of control element IDs

[Takashi Sakamoto]

Hi Jaroslav,

On Thu, Mar 18, 2021 at 06:17:54PM +0100, Jaroslav Kysela wrote:
> Dne 18. 03. 21 v 17:56 Takashi Sakamoto napsal(a):
> > On Fri, Mar 19, 2021 at 01:37:15AM +0900, Takashi Sakamoto wrote:
> >> As I described, your old implementation is not acceptable just by renaming.
> >> Although the idea of inline definitions is itself preferable. I suspect whether
> >> inline definition for your comparison algorithm is really less overhead than
> >> function call.
> >>
> >> Anyway I'll post revised version of patchset later.
> > 
> > Oops. These APIs have arguments with opaque pointers. In the case,
> > inline definition is not available since the layout of structure underlying
> > the pointer is not available for userspace applications. Thus the rest of
> > issue is whether to use 'tuple' or 'fields' in the name of new API.
> > 
> > In my opinion, 'fields' is generic expression and could give impression to
> > application developers that it includes numid field as well. On the other
> > hand, 'tuple' is weak expression somehow and the developers easily find
> > its meaning in alsa-lib documentation (see line 80). When considering about
> > helpfulness to developers, 'tuple' seems to be better than 'fields'.
> 
> With this logic, we can just create snd_ctl_id_compare1, snd_ctl_id_compare2
> functions to force developers to go to the docs.

It's not better since it's against common convention for name of
exposed API. When you work for internal helper function which is not
exposed, it's acceptable. At least, I have never seen such functions
in alsa-lib.

> Perhaps, snd_ctl_id_compare_full() may be better. Tuple is a generic set of
> fields, so there's no change.

As I described, the usage of 'tuple' in the context is in documentation.
In this case, it's not so bad idea and acceptable I think. At least,
it's better than the word 'full' since your comparison algorithm is not
based on full fields by ignoring numid field.

> Again, I don't expect to add other comparison functions soon.

I'd like you to explain about your rejection to add comparison function
according to numid as well as your view of the comparison algorithm as
being exclusive, single, unique than the others when we have many
comparison algorithms for fields of the tuple.


Regards

Takashi Sakamoto