My thoughts and/or rants on Software Development.
In slide 13: Shouldn't ExecutionStrategy be generic (trait ExecutionStrategy[A])?In slide 15: Shouldn't MyImplicits be renamed to MyMixins?
Did your talk was somehow recorded ? I'd love to see/hear it.
Mixing library implicits into a users package object leaks them out to anyone else who does a wildcard import on that package. That's often not what you're after.
@Ittay Thanks for the slide 15 mess-up.As for slide 13: I clarify what a true type-class is in the talk. This slide was showing a simpler variant where we can provide a global default that can be overriden in any of the higher implicit lookup locations.@pedro I believe it was recorded and will be added to http://www.nescala.org@retronym It's a good point, but not what I was getting after. If a library requires a set of implicits available to work (at all) then this is a dependency that you can simplify for a given project by mixing them into the package object. This is especially viable if those implicits are viral; The new library will also not work without the implicits in scope.Also, as an aside, Our style guide discourages the use wildcard imports *and* the IntelliJ plugin really makes that easy (Thanks for all the work you do there).I agree that you may not want to leak implicits. As I stated early in the talk, this slideshow takes some very strong wording because I feel, as a community, we haven't been as careful with implicits as we should be and implicit-view conflicts are just waiting around the bend. This is attempting to swing us into a middleground. As with most design choices, there are situations where importing implicits are acceptable and where pushing them into a package object is not.At this point, I think a lot of cases where wildcard imports are use can be solved using one of the other suggestions in the talk. This final suggestion is targeted at things that wrap java libraries and attempt to clean up inter-op (like scalaj collections or something that makes the google guava library work well with scala). That's the case where you don't control either side of the implicit view and you still need it to be available in most situations for that code base.I think it can also greatly simplify application specific code (where one does not expect things to 'leak' to the community).In any case, this is not a black-and-white thing here. But I do feel strongly that we should try to avoid requiring implicit imports as much as we have been.
Post a Comment