lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <>
Subject Re: Fieldable, AbstractField, Field
Date Tue, 25 Mar 2008 04:46:38 GMT
There have been many major successful libraries where the interfaces  
change from one (major) version to the next.

Programmers are used to it, and quite apt at dealing with it.

But, in the cited case, it is a perfect example where Field being an  
interface and DefaultField being a default implementation would have  
been a good solution.

This allows backwards compatibility for most applications, but more  
advanced implementations are not hindered by being tied to idea of  
what a field should be.

Some would argue that all that Field needs is

FieldData getField(String name); and void setField(String  
name,FieldData data);

and FieldData has

toBytes(); fromBytes()

with various implementations and decorators that easily allows String  
to be used as a FieldData. Since String is final this is a bit more  
difficult since you could not do

class MyString extends String implements FieldData

which is why for common known JDK classes you would have in DefaultField

setString() and getString() and others...

Writing custom versions of IndexReader and IndexWriter was very  
difficult because them being tied to a directory (a set of files). If  
you have an implementation that doesn't need this, you end up with a  
very bad OO hierarchy. We had an implementation that had no concept  
of files, yet you would never have realized that by looking at the  

On Mar 24, 2008, at 6: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