why Filtered and not predictable, why a for each, and not streams? about cactoos HOT 16 CLOSED

@pgermosen I don't think Streams is a good idea in OOP, in general

from cactoos.

@pgermosen as for "predictable" -- I didn't understand. Can you give an example?

from cactoos.

Of course, streams are not oop , but is easy of use.

this example ?

new ForEach(
  new ArrayAsIterable("how", "are", "you"),
  i -> System.out.printf("Item: %s\n", i)
)

jdk 9 forEach in a collection

I understand better this, than the oop approached

List.of("how","are","you").forEach(i-> System.out.printf("Item: %s\n", i) )

from cactoos.

@pgermosen from my experience streams and other message driving architectures motivate split data and methods of its processing.

from cactoos.

Yes that is a motive of use.

But what i want to make a point is the following points for a new api to take in account

• is easy of use
• readability

the example of To sort a list of words in the file

List<String> sorted = new SortedList<>(
  new IterableAsList(
    new TextAsLines(
      new InputAsString(
        new FileAsInput(
          new File("/tmp/names.txt")
        )
      )
    )
  )
);

for me has the same readability than

if (x==true){
if (n==false){
}
if (y==x){
}else{
if (h==s){
}
}
}

from cactoos.

@pgermosen I'm not sure traditional declarative code will be more clear and shorter for this specific task. Moreover, I'm not sure IterableAsList in needed here at all.

from cactoos.

I think api that can be read like this, is clearer(not necessary shorted, sometimes extra text for clarity is a better)
Example 1

    new FileAsInput(
               new File("/tmp/names.txt")
        ).toText().readLines().toSortedList();

Example 2

    new FileAsInput(
               new File("/tmp/names.txt")
        ).toText().readLinesThat(value -> value.contains("Hello") ).toSortedList();

from cactoos.

@pgermosen this "fluent" interface (.toText().readLines().toSortedList()) is very imperative. We want to stay declarative. That's why we need new objects instead of method chaining.

from cactoos.

@yegor256 it's quite declarative. The problem is different: it's always hard to support these fluent things combining smth new from individual objects and using inheritance.

from cactoos.

What is more important
clear and easy code for the using developers using the library/framework
or
to be hard to support the fluent api.

from cactoos.

@pgermosen fluent interface is easy to use only because it's your habit to use it. Also, if you want it, there are plenty of libraries that do exactly the same as Cactoos, but in a traditional way.

from cactoos.

@pgermosen Do you agree with this solution? If yes, could you close this issue? If not, could you explain why not? Thanks for your attention!

from cactoos.

Don't you like the regular foreach yet present in java language? No lambdas needed. Dont make things too complex.

from cactoos.

@pgermosen can we close this issue? Our README states the motivations and design principles behind cactoos, and your request is unfortunately incompatible with them.

from cactoos.

@pgermosen closing due to inactivity

from cactoos.

The job is not in WBS, won't close the order

from cactoos.