lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Proposal about Version API "relaxation"
Date Wed, 14 Apr 2010 18:47:28 GMT
+1, Thanks for this detailed explanation! In my apps I have no problem to define a static default
myself. And passing this to every ctor is easy, so where is the problem? Look at solr, since
we introduced the version param to solrconfig, you have exactly that behavior, but its limited
to this solr installation using this solr config. And you can still override.

Lucene is a library, no application, so it's not in lucene's responsibility to handle such
things. Configuration and configuration objects passing around is an application responsibility.


Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen

> -----Original Message-----
> From: Mark Miller []
> Sent: Wednesday, April 14, 2010 6:58 PM
> To:
> Subject: Re: Proposal about Version API "relaxation"
> On 04/14/2010 12:29 PM, Marvin Humphrey wrote:
> > On Wed, Apr 14, 2010 at 08:30:14AM -0400, Grant Ingersoll wrote:
> >
> >> The thing I keep going back to is that somehow Lucene has managed
> for years
> >> (and I mean lots of years) w/o stuff like Version and all this
> massive back
> >> compatibility checking.
> >>
> > Non-constant global variables are an anti-pattern.
> >
> I think clinging to such rules in the face of all situations is an
> anti-pattern :) I take it as a rule of thumb.
> In regards to this discussion:
> I agree that the Version stuff is a bit of a mess. I also agree that
> many users will want to just use one version across their app that is
> easy to change.
> I disagree that we should allow that behavior by just using a
> constructor without the Version param - or that you would be forced to
> set the static Version setting by trying to run your app and seeing an
> exception happen. That is all a bit ugly.
> Too many users will not understand Version or care to if they see they
> can skip passing it. IMO, you should have to specify that you are
> looking for this behavior. In which case, why not just specify it using
> the version param itself :) E.g. if a user wants to get this kind of
> static behavior, they can just choose to do it on their own, and pass
> their *own* static Version constant to all the constructors.
> I don't think we need to go through this hassle and introduce a less
> than ideal solution just so that users can pass one less param -
> especially when I think you should explicitly choose this behavior
> rather than get it by ignoring the Version param.
> --
> - Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message