Re: Java blunders
taqmcg@gmail.com writes:
The bit that confuses me -- and I agree that Java is not the
only place this happens -- is that everyone agrees that I/O
is complex and difficult. And the first decision that seems
to be made about it is that given this complex, difficult but
critical element that all of our programs need, lets ensure
that the only syntax that is available to address it is a
method/function. Maybe some of the complexity could be
addressed more cleanly if we thought about I/O as fundamental
element of what we are doing through the language design
process rather than something to be bolted on as library (or
libraries) at the end.
We should try to honour Usenet traditions and limit our line
length to something reasonable like 72 characters per line.
I always deem posters who are able to control the line
lengths in theirs posts as more technically competent. If I
would ever need a programmer to give me advises about Java
I/O programming, I would first look among those programmers.
To illustrate this (and I'm designing this as I write it,
trying to illustrate how we could integrate I/O within the
language differently that we do now). suppose that we had the
idea that all variables (both primitives and objects) in Java
were emitters and receivers
We already have
java.util.function.Consumer< T >
and
java.util.function.Supplier< T >
.
We can also build filter objects that serve as
receiver/emitters. With this kind of framework, we might
consider a filter statement of the form
emitter,emitter,... <<filter,filter,...>>
receiver,receiver,... ;
Kind of like
public class Main
{ public static void main( final java.lang.String args[] )
{ final java.util.List< java.lang.Integer >list
= java.util.Arrays.asList( 1, 2, 3 );
java.lang.System.out.println
( list.stream().map( x -> x * x ).
filter( n -> n % 2 == 0 ).reduce( 0,( x, y )-> x + y )); }}
?