Re: [linux-audio-dev] LAAGA: updates, laaga-0.2.0 tarball available

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LAAGA: updates, laaga-0.2.0 tarball available
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Thu Jul 05 2001 - 19:45:55 EEST


Paul Davis wrote:
>
> >Paul, I'd suggest the following (less functions and infinite
> >extensibility without any new functions):
> >
> >typedef int (*LaagaCallback)(laaga_client_t *client, LaagaPropertyId);
> >/* To get callback arg */
> >void *laaga_get_property_custom(laaga_client_t *client,
> >LaagaPropertyId);
> >/* To get sample rate, buffer_size, etc. */
> >int laaga_get_value_integer(laaga_client_t *client, LaagaPropertyId);
> >
> >int laaga_set_property_callback(laaga_client_t *client, LaagaPropertyId,
> >LaagaCallback);
> >int laaga_set_property_custom(laaga_client_t *client, LaagaPropertyId,
> >void *);
> >
> >No other functions (do you want a simple client API, don't you?)
>
> I personally dislike this kind of generic API. And there is a more
> fundamental problem that in order to be type-safe, there is no such
> thing as a "LaagaCallback" type. This isn't a problem in C++, where

There is such thing if you permit to callback to ask for property values
as you see in my proposal. This is also the benefits that callback may
know other properties without the need to change (or to bloat) argument
list.

> templates can help out, and in where libsigc++ already provides this
> kind of thing in a more-or-less perfect way. But in C, this implies
> the usual hack of passing structs with unions around in a public API,
> which I find very unpleasant, *and* it leads to binary incompatibility
> if the union or struct has to change. And I really dislike

Here I don't understand: with my proposal you may *always* grant
backward compatibility (simply avoiding to remove obsolete properties).

You're never forced to drop backward compatibility (of course you can
choose to do that).

This is not true with your solution.

>
> laaga_get_value_integer(...);
> laaga_get_value_float(...);
> laaga_get_value_whatever(...);

I've also a solution to permit to have only
laaga_get_property/laaga_set_property while retaining perfect runtime
type safety, but I doubt you're interested... am I wrong?

> By contrast, once we establish laaga_set_foobar_callback (X, Y, Z),
> then that particular function never changes, and programs that call it
> remain binary compatible across library revisions. But you know what,
> we had this discussion about alsa-lib and the {sw,hw}_params stuff.
>
> I just have a very different philosophy about this kind of interface
> than you do Abramo. I see simplicity and stability in explicitly
> enumerating (growing) set of mutator/access functions; you see
> simplicitly and stability in enumerating a (growing) set of macro
> constants and providing a generic set of functions to use them with.

API functions bloat means to have something that is learnt hardly and
slowly. I'm sure that you too when approach a new API reading it the
first time are somewhat scared by *number* of functions.

To have a lot of properties is much less a problem because they all
share the same get/set/query operating way.

This is what everybody think about ALSA API and it's strange that you
don't see the analogy. You're doing my same mistake and this means
you've not studied the lesson ;-))). Jaroslav think that for ALSA is too
late (and I'm sure we will pay the price for that before next generation
of sound hardware) but it's not too late for LAAGA.

-- 
Abramo Bagnara                       mailto:abramo_AT_alsa-project.org

Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy

ALSA project http://www.alsa-project.org It sounds good!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jul 05 2001 - 19:49:02 EEST