Skip to content

Commit 9c2130a

Browse files
committed
.
1 parent 7aff487 commit 9c2130a

File tree

1 file changed

+46
-0
lines changed

1 file changed

+46
-0
lines changed

content/unpack.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -806,6 +806,52 @@ val config = OtherConfig("www.example.com", 1000, 10000, true)
806806
downloadAsync(config*, retry = true)
807807
```
808808

809+
Each of the above scenarios is a concrete use case for `unpack` and `*`: I expect it to be common
810+
to use `unpack` at a definition site without `*` at the callsite, and similarly common to use `*`
811+
at a callsite without an `unpack` at the definition site. So we should support the two keywords
812+
being used separately or together, and not mandate than a `*` must correspond to an matching
813+
`unpack`.
814+
815+
### Binary Compatibility
816+
817+
An important property of `unpack` is that it can be added or removed after the fact to an existing
818+
method without breaking binary compatibility. For example I should be able to go from existing
819+
methods with separate parameters To methods with a shared parameters via `unpack` without breaking
820+
binary compatibility:
821+
822+
**Before**
823+
```scala
824+
825+
def downloadSimple(url: String,
826+
connectTimeout: Int,
827+
readTimeout: Int) = doSomethingWith(config)
828+
def downloadAsync(url: String,
829+
connectTimeout: Int,
830+
readTimeout: Int,
831+
ec: ExecutionContext) = doSomethingWith(config)
832+
def downloadStream(url: String,
833+
connectTimeout: Int,
834+
readTimeout: Int) = doSomethingWith(config)
835+
```
836+
837+
**After**
838+
```scala
839+
case class RequestConfig(url: String,
840+
connectTimeout: Int,
841+
readTimeout: Int)
842+
843+
def downloadSimple(unpack config: RequestConfig) = doSomethingWith(config)
844+
def downloadAsync(unpack config: RequestConfig, ec: ExecutionContext) = doSomethingWith(config)
845+
def downloadStream(unpack config: RequestConfig) = doSomethingWith(config)
846+
```
847+
848+
This is important because it is an exceedingly common workflow as a library evolves: nobody
849+
knows up front exactly how all their parameter lists will evolve over time, and so nobody will
850+
be able to design the perfect `unpack` structure up front to decide which methods will need
851+
to share what parameters with which other methods. A user thus needs to be able to consolidate
852+
parameter lists into `unpack` parameters without breaking binary compatibility.
853+
854+
809855
### Case Class Construction Semantics
810856

811857
`unpack` may-or-may-not re-create a `case class` instance passed via `config*` to an

0 commit comments

Comments
 (0)