Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider optimizing .equals() operations #455

Open
emmanuelbernard opened this issue Mar 23, 2012 · 8 comments
Open

Consider optimizing .equals() operations #455

emmanuelbernard opened this issue Mar 23, 2012 · 8 comments

Comments

@emmanuelbernard
Copy link
Member

One use case for identity comparison in Java is to optimize .equals() implementations. If two instances are identical identity wise, they must be equal.

The compiler could enforce that automatically so that this use case for Ceylon's === is no longer needed.

Ceylon a == b would become in Java (a==b) || a.equals(b)

@quintesse
Copy link
Member

Just to document a couple of remarks from the Skype discussion:

  1. The spec would have to change to indicate this. Because it would become impossible to write an equals function that always returns false for example.
  2. Passing equals() as a method reference or as a higher order function would suddenly use a slower code-path

@emmanuelbernard
Copy link
Member Author

Not sure why 2. would be the case. the optimization would be an implementation of equals(), no?

@quintesse
Copy link
Member

Well that's because this:

Ceylon `a == b` would become in Java `(a==b) || a.equals(b)`

suggests that it's the test that changes, not the implementation of equals, although I guess that could be done as well, Wrapping the code inside the equals in an if (a== b) { return true; } else { /* wrapped code here */ }

@FroMage
Copy link
Member

FroMage commented May 23, 2012

If we put that optimisation as inserted code at the beginning of each equals() method we don't have to use a let on every call-site and method references to equals will still be optimised.

@FroMage
Copy link
Member

FroMage commented Jun 13, 2012

Will wait for M4.

@FroMage
Copy link
Member

FroMage commented Oct 1, 2012

Optims for M5.

@FroMage
Copy link
Member

FroMage commented Feb 15, 2013

Moving to M6

@FroMage FroMage modified the milestones: 1.2, 1.1 Apr 3, 2014
@FroMage
Copy link
Member

FroMage commented Apr 3, 2014

Moving to 1.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants