I fixed the reply box…
Some experimentations on the top menu that went mad.
1 Like
xD this is just what I blame of xD. By the way… you convinced me with that example, there are place where they are great… I’ll have to learn something (more things to the list) new T.T.
Thanks for your examples 
Considering the current state of iOS and Android, i think at least the plugin submitted to plugin system should follow java 7 specs. Not sure how the build system for the plugins is going to be made, but i guess it will only eat java 7 code.
Maybe it would not be bad to write that as a fat bold headline when the new plugin system launches 
To be somewhat fair here, the splitting of mapping from listener is on purpose because it lets you redefine the mappings against a logical value rather than some object. You can also have multiple listeners, etc… so the Java 8 case would be two calls, not one.
It’s still cleaner. I wished for a way to have “function pointers” since JDK 1.2… and typically end up implementing something that lets me do it even if it’s not compile-time safe.
That’s why Lemur’s input mapper supports adding reflective methods directly… it will be much cleaner in Java 8.
inputMapper.addDelegate(someLogicalFunction, this, “callThisOnSomeEventAction”);
…mine even supports arguments, though since I have some flexibility. So the method can optionally take the event and so on.
I guess Java 8 can’t be that smart about it(?).
Agreed that reflection already made similar things possible, even a slightly bit more flexible since you could evaluate the required arguments at runtime. To a certain point you can have that in java 8 syntax too, but it would require to write a lot of bloating code in order to support various arguments.
Its just a less flexible but nicer way using the method references.
But every time i use reflection i feel like trying to workaround a java limitation. Escaping the compile time saveness always feels wrong to me. Its level 1 of cheating the vm, level 2 would be usage of unsafe.
Yeah, what I’ve wanted forever is something more like C function pointers… only actually type safe. So both the reference and the caller knew “this method takes these arguments” and could deal with it. Groovy closure resolution kind of has this but it’s dynamically typed and scary when things get complicated. 
Well, you are pretty close to C like function pointers now.
public class Reference {
interface QuadFunction<P1, P2, P3, P4> {
void apply(P1 p1, P2 p2, P3 p3, P4 p4);
}
interface QuadMethod<R, P1, P2, P3, P4> {
R apply(P1 p1, P2 p2, P3 p3, P4 p4);
}
Vector getCenter(Vector p1, Vector p2, Vector p3, Vector p4) {
return null;
}
Vector getExtremes(Vector p1, Vector p2, Vector p3, Vector p4) {
return null;
}
Vector doArbitraryProcessing(QuadMethod<Vector, Vector, Vector, Vector, Vector> method, Vector[] data) {
return method.apply(data[0], data[1], data[2], data[3]);
}
public static void main(String[] args) {
Reference reference = new Reference();
QuadMethod<Vector, Vector, Vector, Vector, Vector> getCenterPoint;
getCenterPoint = reference::getCenter;
Vector center = reference.doArbitraryProcessing(getCenterPoint, new Vector[4]);
Vector centerDirectReference = reference.doArbitraryProcessing(reference::getCenter, new Vector[4]);
Vector extremes = reference.doArbitraryProcessing(reference::getExtremes, new Vector[4]);
}
}
whats left to be fully happy would be some language feature to allow typesafe vararg generics… something like:
interface Function<P...>{
void apply(P ... paramters);
}
where
Function<Integer,Boolean> would accepts any function with that signature. If implemented it should be expanded of course.
I’ve only written lambdas for about 6 months, and it’s not something that you will use everywhere, it depends on what type of problem you’re solving. You can’t use break or continue in a stream, but it’s great to use when filtering or sorting.
Writing simple state machines is also something that will use less code with lambdas, might be used for a simple AI (in combination with a Map).
I do think that lambdas is a good feature, but you can solve problems without it.
I suggest that you try to make your objects immutable (if possible) when using streams or multitasking in general, since it will save you from a lot of synchronization issues.
Java’s concurrency package http://docs.oracle.com/javase/tutorial/essential/concurrency/ is something you should have a look at if you’re going to make multithreaded applications, especially Lock, ReadWriteLock, Executor, CountDownLatch and all thread safe collections.
Note that the time for obtaining a lock using the keyword synchronized in synchronized is exponential.
Single core designs is something that you might consider if you’re writing small games, but you will need to go multithreaded if you should be able to use all the hardware; just try to reduce the amount of locks.
1 Like
Just my two cents. I’ve first been a Java programmer, then Scala, then Clojure. Now I mainly do Clojure + Java. What can I say… I’d avoid judging like the one seen in this thread…
Both OOP and FP come down on bytecode (or machine code) from maths, and really both are just interpretations of certain parts of the groups theory. In actuality, they complement each other perfectly, like ying and yang. What you chose for your task depends on how you envision your solution. While OOP may seem straightforward if that’s the only way of thinking you’re fluent with, FP is actually often more consise and clear in writing, allowing for more mathematical and strict representation of your program flow. For example, try reading about LISP fundamentals.
Yes, I’d say that in order to appreciate what FP can give, you have to look into some maths like lambda calculus and types theory. I’d say that you have to do this to even appreciate the full power and implications of OOP. However, often there is no practical need or self-motivation for an average programmer to dive into this (and often no free time even), so most people just hang on to the opportunistic knowledge they’ve got during their expertise and employment-driven study. Don’t misinterpret this for the reality of the essense of either FP or OOP.
As for me, I’d say I prefer FP over OOP mainly because the existing OOP implementations (including Java) are crampy. We’re not getting “real” OOP as in SmallTalk here. At the same time, the implementations of FP we’re getting are more faithful to its “true” nature. In real programs I happen to sometimes combine the two, when their mutual use gives benifits. Don’t get me wrong, for some tasks, Java OOP is just great!
As others have said, some tasks are simpler with FP: most mathematical tasks, multithreading, working with collections, delegating actions and others…
Someone mentioned about mixing of OOP and FP as of mixing English and Chinise… no. More likely like mixing nouns and verbs in your wording (a bit comical exaggerated example ):
OOP: dog consumption food state organism wellness health
FP: protecting barking eating nourishing being improving
OOP + FP: a dog that eats its food is healthy and cheerful.
That being said, I appreciate that JME keeps it with Java 1.6 level because this makes it versatile JVM-wise.
2 Likes