lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trejkaz <>
Subject Re: BytesRef violates the principle of least astonishment
Date Wed, 20 May 2015 23:25:03 GMT
On Wed, May 20, 2015 at 5:12 PM, András Péteri
<> wrote:
> As Olivier wrote, multiple BytesRef instances can share the underlying byte
> array when representing slices of existing data, for performance reasons.
> BytesRef#clone()'s javadoc comment says that the result will be a shallow
> clone, sharing the backing array with the original instance, and points
> to another utility method for deep cloning: BytesRef#deepCopyOf(BytesRef).

I already know how Object#clone() works:

  "By convention, the object returned by this method should be independent of
   this object (which is being cloned). To achieve this independence, it may be
   necessary to modify one or more fields of the object returned by super.clone
   before returning it. Typically, this means copying any mutable objects that
   comprise the internal "deep structure" of the object being cloned
and replacing
   the references to these objects with references to the copies."

As BytesRef#clone() is overriding Object#clone(), I expect it to
comply with that.
Otherwise, it violates the Liskov substitution principle as well.
Essentially, BytesRef
cannot be used as an object.

If Lucene wanted a shallow clone, it could have added shallowClone() while
leaving clone() behaving correctly. I don't think that "it was for performance!"
is an acceptable excuse for not wanting to name methods properly.

Olivier Binda then says:
> Lucene gives the user of the library the choice of how to use the data (which
> is good) instead of creating immutable data for everybody and to make
> people who don't need it suffer the penalty

So basically, you make people who want reliable programs suffer the
penalty. Awesome.


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

View raw message