Re: Removing empty keys from GrlData

["Juan A." Suárez Romero <jasuarez igalia com>]

On Tue, 2011-03-29 at 14:54 +0000, Iago Toral wrote:
> > My doubt comes because in GrlData there are functions to handle
> > single-valued keys and functions to handle multi-valued keys.
>
>  Single valued APIs are there just for the sake of simplifying common 
>  use cases, but this is a multi-valued system at its core  and we should 
>  make our decisions based on that. for that I think we should return TRUE 
>  for mime.

Ok.

> 
> > Now I'm wondering if we should keep the function to handle only
> > single-valued keys. For the case of multi-valued keys, user can 
> > either
> > ask for all GrlRelatedKeys and then checking it related_keys to see 
> > if
> > it has the key, or adding a new function like
> > grl_data_related_keys_has_key(). I feel a bit inclined to do this.
> 
>  I think we would be complicating things more than necessary. We should 
>  think only of the case of multi-valued keys. As I said, the 
>  single-valued API is there only to simplify some common use cases.
> 
>  This is a "test" function, so it is not big deal to only have one 
>  version that deals with all the values. People only caring about 
>  single-values can just forget about has_key and get the first value 
>  directly and test whether it is NULL or not.
> 

Ok.

> >
> > I brought this question because, as it happened with 
> > grl_data_has_key(),
> > grl_data_get_keys() were there to handle single-valued keys.
> >
> > Now I wonder if we should change the semantic (and therefore possibly
> > breaking some client), or introducing a new function to get all keys
> > with some value (something like grl_data_get_all_keys()).
> 
>  I think it is not necessary. We have time to add that in the future if 
>  we see the need for real.
> 

Ok.

> >
> > BTW, in all this task, instead of directly removing/renaming the
> > functions, I'm marking them as "deprecated"; and my plan is to get 
> > rid
> > of them in next or after next release.
> 
>  For something we have just added a few days ago I don't see the need 
>  for that procedure, but I guess you propose it because the previous API 
>  is already in some release.
>  Just wanted to say that probably there is no need for that, but I am ok 
>  with doing it anyway.
> 

Exactly: I only do it for API that was already released.

And yes, very likely it is not needed, but hey, let's try to do the
Right Thing (tm) :)

	J.A.