[Xapian-devel] ruby bindings odds and ends

[Olly Betts]

On Wed, May 10, 2006 at 08:51:54PM -0300, Paul Legato wrote:
> Olly Betts wrote:
> > The ones I'm thinking of are those set_ methods which don't take exactly
> > one parameter, and perhaps those get_ methods which take parameters.
> > 
> > For example, Enquire::set_sort_by_relevance doesn't take any parameters,
> > while Enquire::set_sort_by_value takes two (the second is optional,
> > but it allows you to reverse the sort order which is a common thing to
> > want to do).  Neither of these methods is really a setter method in
> > the usual sense.  They're just methods with names which happen to start
> > "set_".
> 
> The Rubish way to do something like set_sort_by_relevance would be with
> a method called sort_by_relevance!. Method names ending in ! signify a
> method that modifies the internal state of an instantiated object

OK, I've changed "sort_by_relevance=" to "sort_by_relevance!".  That
seems to be the only method which doesn't take any parameters (although
QueryParser::set_stopper has one optional parameter (to disable stop
words if you've enabled them).

> Similarly, I can see something like sort_by_value!(param1,
> param2), if that causes some general internal state of an Enquire object
> to change rather than acting as a setter method for some specific
> instance variable.

OK, I'll go through these shortly.

What about cases where the setter is overload and can take one
parameter?  Do we want a "foo=" for that case (as well as "foo!"
for the general case)?  Perhaps only if the single parameter case
is very commonly used?

And about the "get_foo" methods which take parameters - does it make
sense to rename these to "foo" as we currently do?

(In case it's not obvious, I'm asking the questions because I know
nothing about the Ruby conventions...)

> > I'm also wondering if we should avoid wrapping C++ methods which are
> > deprecated (since there's no previous version of the Ruby bindings to
> > remain compatible with and those methods will be removed at some point,
> > possibly in 1.0 which should happen fairly soon).  This isn't a Ruby
> > specific thought - I think it makes sense generally.
> 
> This sounds like a good idea. No need to get people used to using things
> that are going to disappear :)

OK, I'll turn those off.

Cheers,
    Olly