lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trejkaz <trej...@trypticon.org>
Subject Re: BytesRef violates the principle of least astonishment
Date Wed, 20 May 2015 06:53:20 GMT
On Wed, May 20, 2015 at 3:21 PM, Olivier Binda <olivier.binda@wanadoo.fr> wrote:
> My take :
> Indeed BytesRef is mutable
> This happens for performance reasons, to avoid unnecessary object
> creations and unecessary copying and Also to workaround
> the java "issue" that most of the time  you need to pass an array with an
> offset and length in methods for performance but you don't want to create
> an array every time you have to do that
>
> In your case, you are supposed to copy your bytes because, indeed, the
> bytesRef will change everytime you call a lucene method on it
> (it is mutable) and the array it points to will change too because these
> might be internal arrays of readers/buffers/codecs
> (and you don't know the internal working of those)...

That's fair enough, most of this is a philosophical issue anyway. Some
people prefer reusing objects and overwriting data because they don't
trust GC or whatever. I prefer immutable objects because at least then
when you have an object you can guarantee nobody else can mess with
it.

But that aside, it's still astonishing when the method to clone an
object doesn't actually clone it. There isn't any other obvious method
on BytesRef to perform a copy, either. What are we supposed to do,
pull out the byte array, offset and length manually and then jam it
into another BytesRef? Ew.

TX

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message