forked from scala/scala
-
Notifications
You must be signed in to change notification settings - Fork 3
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
object hash code #45
Comments
no obvious benefit:
on benchmark:
above is optimized version, below is baseline:
|
pkukielka
pushed a commit
that referenced
this issue
Apr 30, 2018
Abstractions for constrained collection types
pkukielka
pushed a commit
that referenced
this issue
Apr 30, 2018
`BuildFrom` is like `FromSpecificIterable` but with an extra `From` argument, like in the final version of #45. `FromSpecificIterable` existed conceptually in that version as `BuildFrom[Any, …]` but didn’t have a separate type. This new version has separate abstractions for buildable (strict) collection types in the form of `StrictBuildFrom` and `FromSpecificIterableWithBuilder`. Since we can get a surrogate builder (through one of the new `Builder.from` methods) for any lazy collection and we can restrict code to work only with strict collections via the `Buildable` trait, this is not strictly necessary. The only reason for separating the `Builder` abstractions is to avoid exposing them in `FromSpecificIterable`. Even though everything can be built in a strict way, these abstractions sit on top of the lazy ones, not below them.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
is it faster to default the hash code or stamp it in?
lots of objects hashcode are frequent, e.g. Nil
small saving - but is an override faster that the default?
The text was updated successfully, but these errors were encountered: