source.fromFile missing

On Wed, Jun 02, 2010 at 10:28:21PM +0200, martin odersky wrote:
> When trying to adapt an example of the Artima book for a course I found that
>
> source.fromFile(name)
>
> no longer works. It has to be source.fromPath. I am OK with the
> change, but we need to keep & deprecate the old usage.

Yeah... I would be all for that, except it's not possible, which is how
it got changed in the first place. You can't overload in the presence
of default arguments, and my whole brilliant idea for making encodings
work right and stay in the background was to use implicit defaults,
which is what you'll see on all those factory methods.

So the only way to put fromFile back is to unroll the whole thing. And
for sure the IO code is in a pitiful state, since I was writing that
code with a bigger picture in mind. I don't even know what works and
what doesn't, I avoid scala.io.* entirely.

Let me know how you'd like me to resolve it. As far as I'm concerned we
can roll scala.io.* back to 2.7.7 and I'll make the minimum changes to
make it compile. No more arrested development for me.

It occurs to me that maybe I can make everything work out by way of
LowPriorityImplicits or an equivalent. When I wrote all that stuff
there was no other way to supply a default implicit, but now that we
have some blunt instruments for designating "the implicit of last
resort" then I believe I could accomplish the same thing that way.

>>>>> "Paul" == Paul Phillips writes:

Paul> So the only way to put fromFile back is to unroll the whole
Paul> thing.

Hmm, how about: the new fromFile, the one that takes a File object and
has default arguments, could have a different name. Like, uh,
"fromFileObject". The old fromFile could go back to the way it was (and
be deprecated).

Paul> As far as I'm concerned we can roll scala.io.* back to 2.7.7

/me breaks out in a cold sweat

On Wed, Jun 02, 2010 at 07:34:12PM -0500, Seth Tisue wrote:
> Hmm, how about: the new fromFile, the one that takes a File object and
> has default arguments, could have a different name. Like, uh,
> "fromFileObject". The old fromFile could go back to the way it was
> (and be deprecated).

I have trouble seeing how that amounts to anything more than musical
chairs on the Titanic.

OK, that seemed to work. Here is the patch.

http://github.com/paulp/scala/commit/a4544b6deeb133d2882156e8f98fa082670...

Everything passes and the sanity check looks sane.

scala> io.Source.fromFile("/etc/passwd")
res0: scala.io.BufferedSource = non-empty iterator

// I would die without the company of Macro-Man
scala> res0.codec.name
res1: java.lang.String = MacRoman

scala> implicit def myCodec = { println("It's all happening") ; io.Codec("ASCII") }
myCodec: scala.io.Codec

scala> io.Source.fromFile("/etc/passwd")
It's all happening
res2: scala.io.BufferedSource = non-empty iterator

scala> res2.codec.name
res3: java.lang.String = US-ASCII

> From: seth@tisue.net
>
> Paul> As far as I'm concerned we can roll scala.io.* back to 2.7.7
>
> /me breaks out in a cold sweat
>

Me too - please do not roll back to 2.7. I would rather have a slight breaking change (perhaps add an immediately-deprecated fromFile0 method, which any new user would hopefully find) than roll back to 2.7. 


Get a new e-mail account with Hotmail - Free. Sign-up now.

On Thu, Jun 3, 2010 at 11:35 AM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

> From: seth@tisue.net
>
> Paul> As far as I'm concerned we can roll scala.io.* back to 2.7.7
>
> /me breaks out in a cold sweat
>

Me too - please do not roll back to 2.7. I would rather have a slight breaking change (perhaps add an immediately-deprecated fromFile0 method, which any new user would hopefully find) than roll back to 2.7. 

The problem is there are 10s of thousands of books out in print that all use the 2.7 version of io.Source. It will be a long time until 2.8 versions of these books are out and until they have replaced the 2.7 versions for all beginning users. If we change io.Source in backwards incompatible ways, the first examples these new Scala users will try will fail. Not good!

Jesse Eichar told us he made good progress in coming up with a coherent IO library building on Paul's Path design. So more will come in the IO space after 2.8 is out.
 As for what to do now, I think it might be best to

 - rename the current io.Source to something else (#3525 will still need to be fixed).

 - roll back to 2.7 for io.Source, but deprecate it.

That's my suggestion.  I am not really an expert on this, so please speak up if you feel differently.

Cheers

 -- Martin

On Thu, Jun 03, 2010 at 11:50:26AM +0200, martin odersky wrote:
> The problem is there are 10s of thousands of books out in print that
> all use the 2.7 version of io.Source.

It'd be kind of nice to have these test cases in hand. If they are
lying around somewhere you could point me at, I can take responsibility
for making sure everything that worked in 2.7 works in 2.8, at least
assuming it's possible. (I think it is.)

Do you have an opinion on the Source patch I sent? I think we can
preserve full source compatibility with 2.7 and still at least make the
modest but important step forward of being able to control the charset.

On Thu, Jun 3, 2010 at 4:14 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jun 03, 2010 at 11:50:26AM +0200, martin odersky wrote:
> The problem is there are 10s of thousands of books out in print that
> all use the 2.7 version of io.Source.

It'd be kind of nice to have these test cases in hand.  If they are
lying around somewhere you could point me at, I can take responsibility
for making sure everything that worked in 2.7 works in 2.8, at least
assuming it's possible.  (I think it is.)

They are not exactly lying around. I copy pasted this one from the artima book source because I wanted toi try it out in a course. There are only a couple of examples anyway.
 

Do you have an opinion on the Source patch I sent? I think we can
preserve full source compatibility with 2.7 and still at least make the
modest but important step forward of being able to control the charset.

From the implicits side the patch looks right to me. from the underlying io.Source side, I am really not able to judge these encoding issues. I believe that maintaining backwards compatibility here is important, because it so basic. But I have no opinion how best to achieve this. If we can have OK functionality for source while maintaining backwards compatibility, great! It's better than forking io.Source into a 2.7 and a 2.8 version, that's for sure.

Cheers

 -- Martin

> The problem is there are 10s of thousands of books out in print that all use the 2.7 version of io.Source. It will be a long time until> 2.8 versions of these books are out and until they have replaced the 2.7 versions for all beginning users. If we change io.Source in> backwards incompatible ways, the first examples these new Scala users will try will fail. Not good!

I agree that this is not great and will not help adoption but the 2.7 I/O package is broken anyway. Try use Source.fromInputStream(System.in).getLines - one of the first things I did on picking up a REPL - and tell me how that is going to reflect on Scala any better.
2.8 is a massive change to scala, everyone in the community understands that. Put clear disclaimers on the download page and links to those (very few) things which are known inconsistencies and a justification as to why it was a breaking change. I feel that motivated developers will understand.
Or put in Paul's fix :-)
Chris



Get a free e-mail account with Hotmail. Sign-up now.