Gerard Gauthier

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

Junilu Lacar wrote:

Gerard Gauthier wrote:You understand that the dot notation is syntactic sugar right?

You keep using that phrase; I don't think it means what you think it means. https://en.m.wikipedia.org/wiki/Syntactic_sugar

The dot notation is a fundamental part of Java syntax and there is nothing you can use in place of it that would make Java programs work the same way, therefore, it is not "syntactic sugar" as you insist on saying.

But my point still stands. The dot notation is just a function call that passes a pointer to the object behind the scenes.

SomeObject.SomeMethod();

and

SomeFunction(SomeObject);

Fundamentally do the same thing. One exposes where the 'this' comes from and the other hides it under a layer of abstraction.

This is one thing I hate about programmers and programming languages and programming paradigms. They try to make their paradigm/language/discipline out to be more than it is.

You understand that the dot notation is syntactic sugar right? There is nothing at the machine level that understands someObject.someMethod(), just like there is nothing at the machine level that understands someFunction(someObject). These are constructs invented in programming languages and both void someFunction(Object * this) {...} and public void someMethod() {...} do the same thing.. Pass a pointer to an object to a function/method.

Junilu Lacar wrote:

Gerard Gauthier wrote:
And when you call the method display, its really:
//syntactic sugar way //myThis.displayThis(); //remove syntactic sugar display(myThis);

No, no, no, no. This is NOT how Java works. It may be close to how Python works but Java is NOT Python and conversely, Python is NOT Java.

You have to understand something... They ALL work like I posted. The Java environment is just a pile of abstractions build on abstractions. When you strip it all away, the 'this' is just a pointer to the calling object and the dot notation is just an abstraction for a function call and a functional call is just an abstraction...

Campbell Ritchie wrote:

Gerard Gauthier wrote:. . . the dot notation is just syntactic sugar. The method display, contained in the ThisDemo class, is really defined like something below.
class ThisDemo { public void displayThis(ThisDemo * this) {//where the * is denoting a pointer to the calling object System.out.println(this); } } . . .

Where on earth did you get that from? There is nothing syntactic sugar‑y about the dot notation. When an instance method is called, the runtime implicitly passes a reference to the relevant object to the method, which lives in the Class<ThisDemo> object, but that is an implementation detail which doesn't even appear in the bytecode.

Yeah, because the environment wouldn't be sugar sitting on top of the hardware.

The first thing you have to learn about this... This is just the object calling the method. Example:

Say we have a class:
class ThisDemo { public void displayThis() { System.out.println(this); } }

And we create an instance of that class myThis:
ThisDemo myThis = new ThisDemo();

Now we call ThisDemo's only method display:
myThis.displayThis();

And now print the value of the instance:
System.out.println(myThis);

You'll find both display the same value because the dot notation is just syntactic sugar. The method display, contained in the ThisDemo class, is really defined like something below.
class ThisDemo { public void displayThis(ThisDemo * this) {//where the * is denoting a pointer to the calling object System.out.println(this); } }

And when you call the method display, its really:
//syntactic sugar way //myThis.displayThis(); //remove syntactic sugar display(myThis);

Monica Shiralkar wrote:

Could you give some examples which Lambda expressions should be used on non-functional interfaces?

I am not talking about non functional interfaces. I am saying the usage of lambda expressions is limited to interfaces in Java 8.  

First thing you have to understand... Java and Scala are two different languages which happen to run on the same environment. Scala, a language designed to embrace functional programming(functions), tends to rely on higher level functional abstractions while Java, a language designed around objects, embraces objects. Its really just a design choice.