- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
a (maybe stupid) thought about implicit arguments
Wed, 2011-11-30, 16:15
body
p { margin-bottom: 0cm; margin-top: 0pt; }
Hi,
Currently, methods like ++ are considered complex:
def ++ [B >: A, That] (that:
TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That])
: That
One reason is the list of implicit arguments. Someone looking at the scaladoc, or IDE completion, needs to figure what it means, what is the role of CanBuildFrom, etc.
What if instead, the implicit arguments were given as a sort of annotation that is interpreted by the compiler to add an implicit argument list, but in general will fall in the "blind" spot of the user.
Something like:
@Implicit(CanBuildFrom[List[A], B, That])
def ++ [B >: A, That] (that: TraversableOnce[B]): That
An experienced developer would know there are more arguments that can be provided, but a casual look in the source/scaladoc will show a very simple signature (without the need for a @usecase in the comment)
(I appologize if the idea is too simplistic.)
Regards,
Ittay
What if instead, the implicit arguments were given as a sort of > annotation that is interpreted by the compiler to add an implicit > argument list, but in general will fall in the "blind" spot of the > user.
>Something like:
>@Implicit(
>CanBuildFrom[List[A], B, That])>
This doesn't strike me as a good idea. In particular, methods of the form: def whatever(foo:Foo)(implicit bar:Bar) ...really does take two parameter lists. If you write code like: whatever(a)(b) You may be surprised to realized that 'b' is being passed for 'bar'. Changing the documentation to "hide" implicit parameters would make these kinds of cases even more mystifying, as well as obscuring the fact that you can pass them explicitly, e.g.: // sort by 'myOrdering' a custom instance of Ordering[Foo] import scala.util.Sorting val myList:List[Foo] = ... val myOrdering:Ordering[Foo] = ... Sorting.quickSort(myList)(myOrdering) If these type signatures are decided to be too hard to read, then the answer is to simplify them (thus loosing functionality) or just create more "usage examples" which show how to use them in practice. I'm intentionally steering clear of the "complexity" argument here.def ++ [B >: A, That] (that: TraversableOnce[B]): That