Adds sbt.io.syntax #3
Conversation
|
LGTM. I like this pattern, and I've been exploring it a lot myself, but I'm still not sure if there's any fall out from it. |
| object RichURI { | ||
| object RichURI extends URIExtra | ||
|
|
||
| trait URIExtra { |
There was a problem hiding this comment.
I'm being consistent with sbt's use of trait in other places like ProjectExtra - https://github.com/sbt/sbt/blob/0.13.8/main/src/main/scala/sbt/Project.scala
There was a problem hiding this comment.
I'm not sure if that's a good style to mimic or not. I'd hate to expose a public trait without a good reason first.
|
To sum up, I like the syntax object/can buy the reasoning. I don't buy the |
|
@jsuereth @dwijnand We should come up with a systematic style of how we enrich classes in the coding guideline sbt/website#189. |
The idea is to introduce a single import that can be used as a DSL. * For the modular usage people can initially use `import sbt.io.syntax._` * IOSyntax can eventually get mixed into `package object sbt`.
|
Updated IO's syntax to be compliant to the coding guideline. |
| } | ||
|
|
||
| import java.io.File | ||
| sealed abstract class IOSyntax0 extends IOSyntax1 { |
There was a problem hiding this comment.
this is a complication I hadn't thought about. We may need to duplicate these hierarchy levels as well in the sbt package object later....
|
This does look a lot better to me. I would be curious how it affects the sbt main package... I'm ok merging now. Little worried about implicit priorities... |
The idea is to introduce a single import that can be used as a DSL.
import sbt.io.syntax._/review @jsuereth, @dwijnand