Gerard Gauthier

I heard a quote (I can't remember who said it) -> "objects are just closures(function closures)".

Now when I first heard this, I thought it was a bit of an exaggeration but I quickly released that I used function closures(to create simple objects) all the time in JavaScript. If you consider that function closures are a way to capture state and function closures can(in most languages) return functions which are tied to the captured state, then you realize you are talking about simple objects minus some syntax conveniences.

What do you think about the claim -> objects are just closures(function closures)?

What if the insert fails?

Jeanne Boyarsky wrote:
....So at some point I have to stop returning optionals.

...

I'll agree that the endpoint of an Optional's mappings need to produce something 'if present' but that's where the Optional type loses its functional credentials and becomes imperative programming.

The proper way(a more functional way) to use an optional value is with map. Example.

public Optional<Btree<T>> find(T data) {    return nde.find(data).map(n -> new Btree<>(n)); }

The above code doesn't expose the enclosed Optional data, The above code map's the value contained in the Optional object and returns a new optional value. The map method will return an empty Optional type when its passed an empty Optional type.

Also note: ArrayList<T> is not fix in size while Arrays.asList(...) is fixed size.

If you consult the Java docs you'll note that Arrays.asList(...) returns a List<T>.

static <T> List<T> asList(T... a) Returns a fixed-size list backed by the specified array.

from Arrays

To really understand what objects and classes are, you have to understand what came before OOP. Before OOP, you had data structures and functionality that operated on those data structures and it was the responsibility of the programmer to make sure they applied the correct functions to the appropriate data structures. Before OOP, there was no contract between data and functionality that operated on that data. OOP created a contract(that is enforced many ways) between data structures and functionality that operates on that data.

Do I really have to point out Campbell Ritchie's link in the above post?

Stephan van Hulst wrote:People think they miss a Pair class, but that's only because they're usually too lazy....

I hate to tell you this, all high level abstractions are there because people are too lazy.

What is it about Java programmers and OOP? Just about every other language enthusiast will embrace new language features that explore other paradigms but not Java enthusiast.. Just look what happened to Java's popularity when it embraced lambdas and streams. Java was on a slow and steady downward trend in popularity until it adopted lambdas and streams... It obvious people want these features in Java.

But that complaint is from a OOP position and most languages are trending towards blending the best of all paradigms. I see Java implementing some form of tuples in the near future.

The tuple or more specifically the 2-tuple, is a data structure that I sorely miss while poking around with Java but I think I found a stand in. The AbstractMap.SimpleEntry<K, V>. Its not a 2-tuple but its close enough and convenient enough and present in the standard library.. Does Java call it a standard library?

Could you post what you tried?

Correction to my earlier post.. Didn't account for the optional max/min.

InfoArray.stream().map(e -> e.getValue()).max(Integer::compare).ifPresentOrElse(e -> System.out.println("Max: " + e), () -> System.out.println("No value")); InfoArray.stream().map(e -> e.getValue()).min(Integer::compare).ifPresentOrElse(e -> System.out.println("Min: " + e), () -> System.out.println("No value"));

For the max and min, I'd try something like below:

InfoArray.stream().map(e -> e.getValue()).max(Integer::compare); InfoArray.stream().map(e -> e.getValue()).min(Integer::compare);

For the PrintSnaller method, you could try something like:

InfoArray.stream().filter(e -> e.getValue() > 30).forEach(System.out::println);