A library for implementing equals and hashCode
Liam Miller-Cushon
cushon at google.com
Tue Apr 23 22:41:09 UTC 2019
Hi Remi,
On Tue, Apr 23, 2019 at 2:54 PM Remi Forax <forax at univ-mlv.fr> wrote:
> Here is my implementation
>
> https://github.com/forax/exotic/blob/master/src/main/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupport.java
>
Thanks for the pointer! I'll add a note to the prior art section.
> I disagree that it has to be included in the JDK, because as you said
> there is no typesafe way to represent a field at compile time so any APIs
> will be either typesafe but slow or less typesafe and faster*.
>
> * It doesn't seems logical that if an API is less typesafe, it can be
> faster at runtime. It's because if you have an API based on strings you
> have less type info at compile time but more type info at runtime thanks to
> the reflection. By contrast, an API based on lambdas will be more typesafe
> but because you can not do reflection on lambdas, so you have less type
> info at runtime.
>
To maybe clarify the mention of performance in the 'non-goals' section,
it's more that it's a long term goal than it is a non-goal. Ultimately we
want the performance to be competitive with hand-written implementations,
perhaps through some combination of intensification, field references, and
lambda cracking.
For the initial discussion I wanted to consider what the best (e.g. most
readable and ergonomic) library version of the feature would look like.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190423/cec891b4/attachment.html>
More information about the amber-spec-experts
mailing list