lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: BytesRef violates the principle of least astonishment
Date Thu, 21 May 2015 15:20:20 GMT
bq: Anyways, really my main problem here is that the Migration Guide says:

Well, then volunteer to clarify them to prevent others from
experiencing your pain,
that's how open source code gets better.

Best,
Erick

On Wed, May 20, 2015 at 11:29 PM, Trejkaz <trejkaz@trypticon.org> wrote:
> On Thu, May 21, 2015 at 9:44 AM, Chris Hostetter
> <hossman_lucene@fucit.org> 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, widely used (in the Java community as a whole)
>> class, such as ArrayList, HashSet, or HashMap etc...  (all of which
>> implement Clonable, and all of which are documented as implementing
>> Object#clone by making a shallow copy)
>>
>> https://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html#clone%28%29
>> https://docs.oracle.com/javase/7/docs/api/java/util/HashSet.html#clone%28%29
>> https://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html#clone%28%29
>
> Yep, this and other quirks are why I now prefer Guava's
> ImmutableList, ImmutableSet and ImmutableMap, where you never need
> to clone anyway.
>
> I guess in the case of ArrayList and friends, their excuse might have been
> that the list is supposed to support whatever object you want, and deep
> cloning would require that all objects you put in the list are cloneable.
> Maybe they weren't happy with requiring that. I don't really know.
>
> I know arrays are notoriously bad at this as well, but that's really just the
> tip of the iceberg when it comes to issues with arrays. (One could also
> complain about equals and hashCode not being implemented sensibly,
> the fact that they don't implement Iterable despite working in a foreach
> loop, the fact that stream() is absent, the fact that they don't all inherit
> from a common base class, and so on. I got sick of all this in arrays
> years ago and more or less switched entirely to using List as soon
> as generics became an option. But that's all history.)
>
> Anyways, really my main problem here is that the Migration Guide says:
>
>         "Note however that it can be costly to convert to String,
>          so it's better to work directly with the BytesRef."
>
> But it doesn't warn at all about the pitfalls of doing so. By the time I had
> discovered the pitfalls, I had already migrated 100% of our code which
> dealt with iterating TermEnum over to TermsEnum and had to redo all of
> it again.
>
> Well, this isn't the only thing missing from the migration guide anyway.
> I know there were other cases where a class had completely
> disappeared and there wasn't even a mention of it changing.
> (In the case of one of them, SortedVIntList, the changelog entry for it just
> mentioned it was being removed, not what the replacement was, so even
> people keen enough to read the *changelog* to find out what's going on
> are SOL.)
>
> TX
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>

---------------------------------------------------------------------
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