From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Jaroslav Kysela <perex@perex.cz>
Cc: alsa-devel@alsa-project.org
Subject: Re: alsa-lib's new API issue (snd_ctl_elem_id_compare)
Date: Fri, 12 Mar 2021 10:35:17 +0900 [thread overview]
Message-ID: <20210312013517.GA412450@workstation> (raw)
In-Reply-To: <bb3e0483-e348-2b9a-14cc-ca01992c73dd@perex.cz>
On Thu, Mar 11, 2021 at 02:22:45PM +0100, Jaroslav Kysela wrote:
> > Hm. I believe that you agree with the fact that we can make various
> > algorithms to compare a pair of IDs for control elements. When focusing
> > on fields except for numid, we can make the other algorithms against your
> > implementation, since the ID structure is compound one. Each of the
> > algorithms can return different result.
> >
> > Here, I'd like to shift the discussion to the name of new API. Although it
> > has the most common name, 'snd_ctl_id_compare', it just has one of
> > comparison algorithms. I have a concern that the name can gives wrong idea
> > to users that the ID structure for control element had design to be able to
> > be compared by itself and it would just be a single comparison algorithm.
> >
> > I suggest to rename the new API to express that it implements one of
> > comparison algorithm. In a case of numid comparison, it would be
> > 'snd_ctl_id_compare_by_numid()'. For your case,
> > 'snd_ctl_id_compare_by_name_arithmetic' or something suitable.
>
> Perhaps, we can add a third argument defining the sorting algorithm, so we
> don't bloat the symbol tables so much when we add a new sorting type (enum).
> It would mean that the function cannot be used as a direct argument to
> qsort(), but I think that the apps add usually an extra code to own callback
> depending on containers, anyway. Is it more appropriate for you?
I've already investigated the idea you describe, however I concluded
that it has more complexity than convenience.
For example, the prototype would be:
```
int new_api(const snd_ctl_elem_id_t *l, const snd_ctl_elem_id_t *r,
int (*algorithm)(const snd_ctl_elem_id_t *,
const snd_ctl_elem_id_t *));
```
For usage with qsort_r(3), programmer should do:
```
int my_algo(const snd_ctl_elem_id_t *l, snd_ctl_elem_id_t *r)
{
...
}
qsort_r(base, nmemb, size, new_api, my_algo);
```
On the other hand, the API has name to express itself appropriately and
we have some of such APIs:
```
int the_api_by_algo_a(const snd_ctl_elem_id_t *l,
const snd_ctl_elem_id_t *r);
int the_api_by_algo_b(const snd_ctl_elem_id_t *l,
const snd_ctl_elem_id_t *r);
int the_api_by_algo_c(const snd_ctl_elem_id_t *l,
const snd_ctl_elem_id_t *r);
...
```
The programmer selects one of them, then:
```
qsort(base, nmemb, size, the_api_by_algo_a);
```
Or select one of them dynamically if need:
```
int (*algo)(const snd_ctl_elem_id_t *, const snd_ctl_elem_id_t *);
switch (cond) {
case A:
algo = the_api_by_algo_a;
break;
case B:
algo = the_api_by_algo_b;
break;
case C:
algo = the_api_by_algo_c;
break;
default:
return -EINVAL;
}
qsort(base, nmemb, size, algo);
```
For the case of hctl/mixer container about which you mentioned,
qsort_r(3) style is convenient for the case that programmer need to
re-implement own comparison algorithm. However the decision is still
up to the programmer, in short:
```
int my_algo(const snd_ctl_elem_id_t *l,
const snd_ctl_elem_id_t *r,
void *arg);
qsort_r(base, nmemb, size, my_algo, my_arg);
```
Here, I think it more worth to share algorithms than keeping less entries
in symbol table in shared library. Just the thought of it, I can devise
some algorithms below:
* by numid
* by name arithmetic (=your implementation)
* by the words 'playback' and 'capture', case-insensitive or sensitive
* by device and subdevice
Regards
Takashi Sakamoto
next prev parent reply other threads:[~2021-03-12 1:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 12:58 alsa-lib's new API issue (snd_ctl_elem_id_compare) Takashi Sakamoto
2021-03-08 14:33 ` Jaroslav Kysela
2021-03-09 0:38 ` Takashi Sakamoto
2021-03-09 12:37 ` Jaroslav Kysela
2021-03-11 12:46 ` Takashi Sakamoto
2021-03-11 13:22 ` Jaroslav Kysela
2021-03-12 1:35 ` Takashi Sakamoto [this message]
2021-03-12 10:09 ` Jaroslav Kysela
2021-03-14 1:41 ` Takashi Sakamoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210312013517.GA412450@workstation \
--to=o-takashi@sakamocchi.jp \
--cc=alsa-devel@alsa-project.org \
--cc=perex@perex.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).