dbus_message_get_args suggestion

[John (J5) Palmieri]

On Tue, 2005-08-02 at 13:06 +0000, Piotr Zielinski wrote:
> Could you tell me what you think about the following suggestion?
> 
> Summary:
> 
> Introduce a variant of dbus_message_get_args from dbus-message.c, with a
> different name, that differs from the original in the way it handles container
> types (arrays, structs,  etc.).  For these, the new function would return the
> iterator ready to iterate over the container.  For example, consider a method
> call with the signature "isa{ss}".  Then we could write,
> 
> const char *string;
> dbus_int32_t number;
> DBusMessageIter hashiter;
> 
> dbus_message_get_args_new_variant(message, error, 
>   DBUS_TYPE_STRING, &string,
>   DBUS_TYPE_INT32, &number,
>   DBUS_TYPE_ARRAY, &hashiter,
>   DBUS_TYPE_INVALID);
>
> and use hashiter to iterate over entries from the "a(ss}" component.
> 
> 
> Justification:
> 
> Currently, you can read the arguments of a message either directly (with
> dbus_message_get_args) or using an iterator.  Usually, the former approach is
> more convenient because it requires less code and auxiliary variables.  However,
> some complex types can't be handled by dbus_message_get_args.  True,
> dbus_message_get_args can handle some container types (eg. an array of string),
> but it will never be able to handle hash tables as standard C libraries do not
> provide such data structures, and I don't think adding GLib dependencies is a
> good idea.  For more complicated types, it's likely that the user will need to
> handle them is a special way, which the dbus library does not implement. 
> Moreover, even if the dbus library can magically do that, this would require a
> dynamic allocation of complex data structures, which might be tricky to
> deallocate (just think of freeing something like "a(ia{ss})").
> 
> Iterators solve this problem, but as I said before, they are not convenient for
> simple types, which are most common.  
>
> It has happened to me a few times that I
> had a function taking a couple of simple arguments, say "ssiii", and then I had
> to add a complex one, getting say "ssiiia{ss}".  Ideally, I'd like to add just a
> new entry to the dbus_message_get_args call, and get the iterator for the hash
> table "a{ss}" along with five other parameters.  However, at the moment a single
> parameter like "a{ss}" forces me to use iterators for the first five parameters
> as well, which only clutters the code.
> 
> If you think providing a new variant of dbus_message_get_args is a good idea, I
> can write a patch that implements it.
> 
> Piotr

I think that providing a hybrid way of getting arguments is not really
something that should go into the API (plus having vargs returning
variables of different contexts is just asking for trouble).  Note that
when we moved to the recursive system we got rid of a bunch of
convinience functions in favor of a more generic aproch.  The lowlevel
API is really geared for writting bindings ontop of them.  My advice is
to either use the existing bindings or write higherlevel C bindings
which hide the complexity of iterators and containers.  There has been
talk of both a pure C++ and C bindings though I have yet to see much
code in that direction.

By the way, using iterators to get all of the parameters is not ugly at
all IMHO.  It is a bit verbose but really not hard to look at and
understand what is going on.

-- 
John (J5) Palmieri <johnp at redhat.com>