An interesting consequence of Scala 3's context functions is that since the parameter's name isn't chosen at the call site (it's implicit), it's often accessed using a helper method, and that method will have a consistent canonical name across codebases. That helps readability.
-
Show this thread
-
For example, imagine an HTTP server's request handler is typed `Request ?=> Response`, so the request object is "given" within its body at the callsite. Defining, def request(using Request) = summon[Request] in the library means the request will always have the name `request`.
3 replies 0 retweets 6 likesShow this thread -
Replying to @propensive
Either this or everything will have names summon[Blah]
1 reply 0 retweets 1 like -
Replying to @actinglikecrazy
If a shorter name for `summon` could have been found, I might have preferred that, actually. I still use `summon` in place of named `using` parameters because it's more explicit about what it's doing, and means I can use context bounds.
1 reply 0 retweets 0 likes -
Replying to @propensive
I liked the initial proposal to rename `implicitly` to `the`. It seemed like at least for smaller projects you can avoid defining all these custom summon methods. But having short functions in global scope has drawbacks, I guess.
1 reply 0 retweets 0 likes -
Replying to @actinglikecrazy
I was thinking about `the` when I wrote my last reply, but mostly because I hated it as the name of a thing! I'm fine with naming methods after nouns, verbs and prepositions in code... but an article just seemed wrong!
1 reply 0 retweets 0 likes
Long ago, my hope was that it would be possible to have parsable syntax that allowed *no* method name to be used, so you would just write the type inside square brackets to get the contextual instance... but that didn't work out.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.