Re: Operation options (filtering, sorting and more)

[Iago Toral <itoral igalia com>]

On Tue, 15 Mar 2011 17:48:07 +0100, Guillaume Emont <gemont igalia com> 
wrote:
> 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.

Agreed.

> > 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.

I so do I.

> > 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.

And as I said in another e-mail, I think that is the best way to go 
too.

Iago