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. Having a non-constant
global determine library behavior which results in silent failure (search
results degrade subtly, as opposed to e.g. an exception being thrown) is a
particularly insidious anti-pattern.
In the Perl world, where modules are very heavily used thanks to CPAN, you're
more likely to come across the action-at-a-distance bugs spawned by this
anti-pattern. I have direct experience debugging such usage of global vars.
It is extremely costly and frustrating.
For instance, there was one time when some module set the global variable
$YAML::Syck::ImplicitUnicode to a true value. Whether or not that module was
loaded affected how YAML::Syck's Load() function would interpret character
data in completely unrelated portions of the code. As with subtly degraded
search results, the result was silent failure (incorrect text stored in a
database). It took many hours to hunt down what was going wrong because the
code that was causing the problem was nowhere near the code where the problem
manifested. The authors of the affected code had done nothing wrong, aside
from using a poorly designed module like YAML::Syck.
I am strongly opposed to using a global variable for versioning because I do
not wish to impose such maddening debugging sessions on a handful of unlucky
duckies who have done nothing wrong other than to choose Lucene as their
search engine library.
This shouldn't be controversial. The temptations of global variables are
obvious, but their flaws are well understood:
http://www.google.com/search?q=global+variables+evil
It is to be expected that the global would work most of the time. This design
flaw, by nature, disproportionately afflicts a small number of users with
action-at-a-distance bugs. Knowingly choosing to impose such costs on a
random few is deeply unfair.
> I also am not sure whether it in the past we just missed/ignored more back
> compatibility issues or whether now we are creating more back compat. issues
> due to more rapid change.
It would be hard to search the archives to confirm my recollection, but I seem
to remember back compat for Analyzers coming up every once in a while -- say,
in the context of modifying StandardAnalyzer's stoplist -- and changes not
being made because they would change search results.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
