Re: Operation options (filtering, sorting and more)

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

On Fri, 2011-03-18 at 11:20 +0000, Iago Toral wrote:
> >> 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.


Obviously, if I propose that is because I fear the contrary. But seeing
both of you are up to have just one GrlOptions, and while I have a
"fear" I do not have very strong reasons to support it, I'm fine with
it.


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

Fine for me too.


	J.A.