Re: Operation options (filtering, sorting and more)

[Guillaume Emont <gemont igalia com>]

On 15/03/2011 17:24, Juan A. Suárez Romero wrote:
> On Tue, 2011-03-15 at 16:43 +0100, Iago Toral Quiroga wrote:
>> Yes, I think Juan made a good point about this in another e-mail.
>> Let's
>> merge flags, skip and count in the options then.
>>
> 
> 
> One things that concerns me is about this merging of lot of things in
> the same GrlOptions: seems we are adding a lot of API in there to handle
> lot of unrelated stuff.
They are related: they are all options to an operation.
> 
> And I feel it worse if in future new options appears.
> 
> One approach to minimize this feeling could be splitting the options in
> related stuff.
> 
> That is, for instance, having a GrlOptionsSort object/structure with the
> api related to do sorting, and having GrlOptionsFilter with the api to
> handle filtering.
I fear that solution could make things even more complicated than the
problem it's trying to solve.
> 
> Both might inherit from a parent GrlOptions, and even this GrlOptions
> could be an aggregation of different options: source would get a
> GrlOptions element, and it could extract from it the GrlOptionsFilter
> and the GrlOptionsSort to do the job.
Well, in the future, if we really feel it's needed, I guess we can
regroup some members of the GrlOperationOptions structure into some
structures, but I really can't see the point of having these structures
inherit from GrlOperationOptions. I think a good rule of thumb for that
is "if you can do it with composition, don't do it with inheritance".

Let me restate another idea to simplify the GrlOperationOptions
structure: separate options and capabilities.

Guij
> 
> This means that we could extend the options in future with new choices,
> keeping them separated and not having a big blob of choices.
> 
> 
> 	J.A.
> 
> 
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list
>