On Sat, Jan 29, 2011 at 8:09 PM, Jörn Kottmann <[email protected]> wrote:
> For all that we gain a little convienence that it is possible to use a
> for-each loop instead of a while loop.
It's not really for-each loop vs. while loop. It's interop with other
libraries that know about standard APIs like Iterator, but know
nothing about non-standard APIs like ObjectStream. For example, if
your stream is an Iterator, in Scala you can write:
stream.filter(!_.startsWith("#")).take(100)
to get the first 100 lines that don't start with "#". Or:
stream.map(_.toInt).sum
to convert all the lines to integers and take the sum. This is
possible because Scala knows about standard Java APIs, and Iterators
automatically gain method like map and filter. ObjectStreams, being a
non-standard API, do not gain such methods.
For a pure Java example, take a look at
com.google.common.collect.Iterators which provides a variety of useful
methods for filtering, etc. over Iterators. Again, these will all work
if you can get an Iterator from an ObjectStream, but they're useless
if you can't.
> Here I have a completely different opinion, handling the IO errors
> is not a "low level detail" only some users should care doing.
[snip]
> Why would it make sense for us to add a feature which leads to buggy
> user code?
I think we have a basic disagreement about what is buggy user code and
what isn't. I believe that declaring a method as "throws" is not buggy
code, and I believe that using RuntimeExceptions instead of checked
exceptions is not buggy code as long as they're declared to be thrown
(e.g. like SecurityException on File.getAbsolutePath). But I don't
think we're going to come to an agreement on this issue, so let's set
it aside.
The main reason to add the feature is to allow your users to take the
countless number of existing libraries that can do useful things with
Iterators and apply them to your ObjectStreams.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
