Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

battling implicits for String.lines (augmentString and stringToProcess) #5994

Closed
scabug opened this issue Jun 28, 2012 · 10 comments
Closed

battling implicits for String.lines (augmentString and stringToProcess) #5994

scabug opened this issue Jun 28, 2012 · 10 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Jun 28, 2012

in both 2.9 and 2.10.0-M4:

scala> import sys.process._
import sys.process._

scala> "foo".lines
<console>:11: error: type mismatch;
 found   : String("foo")
 required: ?{def lines: ?}
Note that implicit conversions are not applicable because they are ambiguous:
 both method augmentString in object Predef of type (x: String)scala.collection.immutable.StringOps
 and method stringToProcess in trait ProcessImplicits of type (command: String)scala.sys.process.ProcessBuilder
 are possible conversion functions from String("foo") to ?{def lines: ?}
              "foo".lines
              ^

I'm working around it by writing {code}stringToProcess("foo").lines{code}, but I have a sad.

@scabug
Copy link
Author

scabug commented Jun 28, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5994?orig=1
Reporter: @SethTisue

@scabug
Copy link
Author

scabug commented Jun 28, 2012

@dcsobral said:
I'm not sure this is worth pursuing. Process implicits are not default, and "lines" works if you use the Process factories. That is, this works:

    Process("foo").lines

And if you want to use lines with String, don't import sys.process._.

@scabug
Copy link
Author

scabug commented Jun 28, 2012

@SethTisue said:
thanks for the superior workaround

@scabug
Copy link
Author

scabug commented Jun 28, 2012

@SethTisue said (edited on Jun 28, 2012 5:04:35 PM UTC):
as for the worthiness of pursuing this, your point only addresses half the issue. what if it's the StringOps one I wanted...? (yes, I can work around it, but it's sad that I would have to)

a further sad: io.Source calls it "getLines" instead of "lines"

@scabug
Copy link
Author

scabug commented Jun 28, 2012

@dcsobral said:
If you want the one on StringOps, do not import sys.process._. If you use the Process factory, there's no need to import those implicits.

But, yeah, getLines makes sense. I'd support that, though, of couse, we need to go through deprecation period.

@scabug
Copy link
Author

scabug commented Jun 28, 2012

@SethTisue said:
"if you use the Process factory, there's no need to import those implicits" — hmm, mrggh, grumble grumble grumble. there is less need. there are a lot of implicits in this API, and the current documentation leans on them heavily. it's pretty much assumed that "import sys.process._" is the standard way to use the API.

@scabug
Copy link
Author

scabug commented Jun 28, 2012

@dcsobral said:
I double checked and all implicits I can find are Source and Sink factories, mostly ProcessBuilder (which is both Source and Sink), with some specialized stuff. I then looked at object Process and all of them seem to be available there.

Now, I plead guilty on the over-emphasis on the implicit conversions in the documentation. In my flimsy defence, I plead that adding Process() everywhere makes for long lines and makes the code ugly. I'll grant that I should have make it very clear -- and with examples -- that you can do all of that without the implicits.

@scabug
Copy link
Author

scabug commented Jun 28, 2012

@SethTisue said:
heh, I forgot the author of the documentation was you :-)

@scabug
Copy link
Author

scabug commented Jul 2, 2012

@adriaanm said:
Daniel, I'll assign to you for the documentation half of the problem.
The other half is up for grabs by community :-)

@scabug
Copy link
Author

scabug commented Feb 1, 2014

@Ichoran said:
Fixed (or at least I have a proposal...will need to fix tests). scala/scala#3454

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants