This repository has been archived by the owner on Dec 22, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 72
Add reusable methods for implementing transformation operations in a strict way #325
Comments
We should then use that to implement the missing |
julienrf
added a commit
to julienrf/scala
that referenced
this issue
Jun 11, 2018
Add StrictOptimizedMapOps and StrictOptimizedSortedMapOps. Only operations that were implemented more than once have been factored out. Some other operations could be factored out so that they could be reused by custom collection implementations. Fixes scala/collection-strawman#325
julienrf
added a commit
to julienrf/scala
that referenced
this issue
Jun 19, 2018
Add StrictOptimizedMapOps and StrictOptimizedSortedMapOps. Only operations that were implemented more than once have been factored out. Some other operations could be factored out so that they could be reused by custom collection implementations. Fixes scala/collection-strawman#325
julienrf
added a commit
to julienrf/scala
that referenced
this issue
Jun 20, 2018
Add StrictOptimizedMapOps and StrictOptimizedSortedMapOps. Only operations that were implemented more than once have been factored out. Some other operations could be factored out so that they could be reused by custom collection implementations. Fixes scala/collection-strawman#325
julienrf
added a commit
to julienrf/scala
that referenced
this issue
Jun 22, 2018
Add StrictOptimizedMapOps and StrictOptimizedSortedMapOps. Only operations that were implemented more than once have been factored out. Some other operations could be factored out so that they could be reused by custom collection implementations. Fixes scala/collection-strawman#325
julienrf
added a commit
to julienrf/scala
that referenced
this issue
Jul 4, 2018
Add StrictOptimizedMapOps and StrictOptimizedSortedMapOps. Only operations that were implemented more than once have been factored out. Some other operations could be factored out so that they could be reused by custom collection implementations. Fixes scala/collection-strawman#325
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Copy pasting the comment here:
I was also wondering if we should provide helpers to implement such operations in a strict way. For the view based version it is as easy as writing:
We should probably have an equivalent strict version:
So that users could just write:
And we could use it also in
StrictOptimizedIterableOps
.The only part that I don’t like is that the builder is created in one place (user code) and used in a different place (framework code). This can be error prone because we really want the builder to be freshly created.
The text was updated successfully, but these errors were encountered: