> Otherwise, it violates the Liskov substitution principle as well.
Sadly it also violates the Heisenberg's principle at the bit state
energy levels. We're working on improving that.
>From your heated comments I think you should switch the language to
something that guarantees immutability of any
On Thu, May 21, 2015 at 9:44 AM, Chris Hostetter
wrote:
> If you really feel strongly about this, and want to advocate for more
> consistency arround the meaning/implementation of "clone()" in Java APIs,
> i suggest you take it up with the Open JDK project, and focus on a more
> high visibility, w
: I already know how Object#clone() works:
May i humbly suggest that you: a) relax a bit; b) keep reading the
rest of the javadocs for that method?
: As BytesRef#clone() is overriding Object#clone(), I expect it to
: comply with that.
BytesRef#clone() functions virtually identical to the way O
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, sha
I was searching a solution for this cross doc AND and found this:
TwoPhaseIterator:
Description
Currently some scorers have to do a lot of per-document work to determine if a
document is a match. The simplest example is a phrase scorer, but there are
others (spans, sloppy phrase, geospatial, etc
> BytesRef is not different, because it is just a "reference" to pass around.
> And cloning a reference for sure should not clone the target of the
> reference. You are "cloning" the reference and only that (as the name of the
> class says: Bytes*Ref*)!
Exactly. It is a reference and as such, c
Hi,
> > 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).
>
> There is no hard contract for clone
> https://docs.or
On Wed, 2015-05-20 at 09:12 +0200, 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, s
On 05/20/2015 08:53 AM, Trejkaz wrote:
On Wed, May 20, 2015 at 3:21 PM, Olivier Binda 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
Yes, BytesRef can be surprising. No, it probably won't change in
Lucene to comply with superb design principles. Yes, the odd design is
there for performance reasons and it does provide noticeable gain.
Perhaps you could file a JIRA issue to improve the documentation, this
would be helpful. For wh
On Wed, May 20, 2015 at 3:21 PM, Olivier Binda 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
>
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
12 matches
Mail list logo
