lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Fieldable, AbstractField, Field
Date Tue, 25 Mar 2008 00:14:58 GMT
Yeah, I tend to think Open Source development should favor abstract  
classes, since there is no way of knowing all the different things so  
many varied users will come up with over time.  I suppose one could  
argue for more "major" upgrades to offset that, or more relaxed rules  
about interfaces changing (which I have argued for.)  I still think,  
given the significant amount of time between our releases, the  
supposed "hurt" of adding to an interface would not be as great as  
people think.  Still, I don't know that I want to find out,  
either :-)  I also think there are means available of communicating  
the changes significantly in advance as to minimize the alleged pain  
that is coming.  Do people really do 1 year plus designs of search  
engines, where they don't expect to upgrade at all?  I would guess  
most of our releases have new functionality that people end up  
changing their code to take advantage of, so, again, an interface  
change may not be as painful as it once was, especially since the code  
is pretty darn mature.

In the end, I don't know what the right answer is.  I remember early  
in my career I didn't see much point in interfaces and favored  
abstract classes, then someone made me "see the light" and then coming  
into Lucene land, I went back to favoring abstract classes.   Now, I  
think I tend to use each one where it makes sense, but that is at the  
application level, and I control the touch points, so, it doesn't  
really apply at the Lucene level.


On Mar 24, 2008, at 7:20 PM, Doug Cutting wrote:

> Steven A Rowe wrote:
>> In the comments on the blog post, the author (Kirill Osenkov)  
>> agrees with a dissenter (Alexander Jung, a.k.a. "AJ.NET"), who re- 
>> states the rule of thumb as:
>> "An interface should define at most one contract."
> But what if you want to expand the contract?  For example, Field was  
> initially just <String,String>, a fine contract.  Field has been  
> generalized to be <String,String|Bytes|Reader|TokenStream>, all  
> without breaking applications.  While in hindsight this evolution  
> may seem obvious, no one forsaw it.  APIs that are too general are  
> confusing. It's best to be clear about what's supported and what's  
> not.  Over time, one may add more features, generalize, introduce  
> new levels of indirection, etc., as demand warrants.  It is  
> impossible to know which APIs will grow in advance, and wrong make  
> them overly general from the start.  So they must evolve.  But if  
> you break applications in the process you waste too much of your  
> time responding to confused users instead of making progress.  Also,  
> happy users lead to more contributors and a stronger project.   
> Interfaces do little to help this process and much to hinder it.
> Doug
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message