-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Make unified collection serialization opt-in instead of opt-out #7624
Conversation
Any takers? This looks big but it's really just factoring out |
@SethTisue, could you look into this one? |
} | ||
new DefaultSerializationProxy(f, this) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, developers who want to implement a custom collection type can mix this trait to support the proxy-based serialization?
class MyCollection[A]
extends Iterable[A]
with IterableOps[A, MyCollection, MyCollection[A]]
with DefaultSerializable { … }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's what most of the collection classes are doing now (except from some wrapper classes like the Java/Scala converters which use the default serialization)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs (trivial) rebase. after that, let's merge this.
rebased |
Porting changes from scala/scala#7624.
…-RC1 failure (#479) * Add a workaround for classloader issues around sbt scala/scala#7624
Fixes scala/bug#11192