Re: [PATCH 00/15] Capabilities and Options

[Guillaume Emont <guijemont igalia com>]

Excerpts from Juan A. Suarez Romero's message of Mon Dec 12 16:00:56 +0100 2011:
> On Fri, 2011-12-02 at 18:36 +0100, gemont igalia com wrote:
> > The operation options consist in an object passed for each operation
> > (_resolve(), _browse(), _search(), _query()) to specify "options" that
> > define
> > how the operation should be carried out. As of this patchset, the list
> > of
> > options is rather limited (skip, count and flags, which were
> > previously passed
> > as individual arguments), but the big advantage of this approach is
> > its
> > extensibility: new options can be added without breaking API or ABI. I
> > have
> > other patch sets waiting that depends on this extensibility to add the
> > ability
> > to filter results. 
> 
> 
> Just a brief question: why we not name grl_operation_options_foo() to
> just grl_options_foo()?
> 
> I think a shorter name would be easier to remember and type, and it
> would be more similar to grl_caps_foo().
> 
> I know that we added the "_operation_" tag because those options are
> related with operations, but to be honest, I don't envision any other
> place where "options" will be added, so I think it would be safe to just
> skip that "_operation_" tag.
> 
> Just a proposal, but what do you think?

It makes sense in a way, but I am afraid things would not be clear enough, and
new programmers might be confused between GrlConfig and GrlOptions if both
exist. My rule of thumb for these things tend to be "go for the most explicit
version", and my rationale for this is that code is written once and read many
times, so I prefer to favour readability over ease of writing.
But then, the question is whether the longer or the shorter name is the most
readable.

Guij
> 
>     J.A.
>