dbus_message_get_args suggestion

[John (J5) Palmieri]

On Thu, 2005-08-04 at 12:26 +0100, Piotr Zielinski wrote:
> Thanks for the replies.
> After reading your replies, I'd propose even a more drastic change. 
> Since, for bindings, consistence and clarity of API is more important
> than convenience,  what about dropping explicit support for some
> container types (arrays of strings) from get_args()?  These values can
> be easily constructed from the iterator anyway.  The advantage of this
> approach is a clear API contract for get_args(): values for basic
> types, iterators for others, and no dynamic memory allocation.   This
> way, one can use get_args() for fixed size types (function parameters,
> structs, dictionary entries) and iterators for variable-size types
> (arrays).  In addition to removing about 50 lines from get_args(),
> this change would also remove free_dbus_string_array() from the API. 
> The disadvantage of this solution is of course breaking the
> applications that rely on the current behaviour of get_args().

I kind of like the idea but being that get_args is used in a lot of apps
I don't know if it is prudent at this point.  Of course we are not at
1.0 yet so...  It is a tough call and people would scream if the change
went in.  I don't know if it is worth the trouble.  Havoc, what are your
thoughts?

The other option is to create new types i.e. DBUS_TYPE_FOO_ITER and
deprecate the use of DBUS_TYPE_FOO for complex types.  In any case I
like having a separate type for iters because it tells you what it is
returning (and lets us know the programmer know what is going to happen
so if they do send in a type that is not supported we can return an
error). 

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