[ 
https://issues.apache.org/jira/browse/LUCENE-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789901#action_12789901
 ] 

Mark Miller commented on LUCENE-2126:
-------------------------------------

> I disagree with you here: introducing DataInput/Output makes IMO the API
> actually easier for the "normal" user to understand.

>> I agree with everything you say in the second paragraph, but I don't see how
>> any of that supports the assertion you make in the first paragraph.

Presumably, because the "normal" user won't touch/see the IndexInput/Output 
classes, but more likely may deal with DataInput/Output - and those classes
being limited to what actually makes sense to use for them (only exposing 
methods they should use) - thats easier for them.

I was leaning towards Marvin's arguments - it really seems that documentation 
should be enough to steer users against doing something stupid - there is no
doubt that writing attributes into the posting list is a fairly advanced 
operation (though more "normal" than using IndexInput/Output). On the other 
hand though, 
I'm not really sold on the downsides longer term either. The complexity 
argument is a bit over blown. If you understand anything down to the level of 
these classes, 
this is a ridiculously simple change. The backcompat argument is not very 
persuasive either - not only does it look like a slim chance of any future 
issues - at this 
level we are fairly loose about back compat when something comes up. I think 
advanced users have already realized, the more you dig into Lucene's guts, the 
more likely you won't be able to count on jar drop in. Thats just the way 
things have gone. I don't see a looming concrete issue myself anyway. And if 
there is a
hidden one, I don't think anyone is going to get in a ruffle about it.

So net/net, I'm +1. Seems worth it to me to be able to give a user 2125 the 
correct API.

I could go either way on the name change. Not a fan of LuceneInput/Output 
though.

> Split up IndexInput and IndexOutput into DataInput and DataOutput
> -----------------------------------------------------------------
>
>                 Key: LUCENE-2126
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2126
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: Flex Branch
>            Reporter: Michael Busch
>            Assignee: Michael Busch
>            Priority: Minor
>             Fix For: Flex Branch
>
>         Attachments: lucene-2126.patch
>
>
> I'd like to introduce the two new classes DataInput and DataOutput
> that contain all methods from IndexInput and IndexOutput that actually
> decode or encode data, such as readByte()/writeByte(),
> readVInt()/writeVInt().
> Methods like getFilePointer(), seek(), close(), etc., which are not
> related to data encoding, but to files as input/output source stay in
> IndexInput/IndexOutput.
> This patch also changes ByteSliceReader/ByteSliceWriter to extend
> DataInput/DataOutput. Previously ByteSliceReader implemented the
> methods that stay in IndexInput by throwing RuntimeExceptions.
> See also LUCENE-2125.
> All tests pass.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to