why Filtered and not predictable, why a for each, and not streams?

[pgermosen]

No description provided.

[yegor256]

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

[yegor256]

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

[pgermosen]

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) )

[akryvtsun]

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

[pgermosen]

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){
}
}
}

[akryvtsun]

@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.

[pgermosen]

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();

[yegor256]

@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.

[akryvtsun]

@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.

[pgermosen]

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.

[yegor256]

@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.

[fabriciofx]

@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!

[andriyshevchenko]

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

[llorllale]

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

[llorllale]

@pgermosen closing due to inactivity

[0crat]

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