rogerkeays

Andrews PW, Thomson JA Jr. The bright side of being blue: depression as an adaptation for analyzing complex problems. Psychol Rev. 2009 Jul

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2734449/

Good point. Actually the plugin didn't handle this case either (fixed now). Thanks for the feedback.

You don't think it would limit the independent use of f()?

This language looks really cool. Thanks for sharing.

You can also rethrow checked exceptions as runtime exceptions by exploiting type erasure:

    public static RuntimeException unchecked(Exception e) {
        Exceptions.<RuntimeException>throw_checked(e); 
        return null; 
    }
    private static <E extends Exception> void throw_checked(Exception e) throws E {
        throw (E) e;
    }

then you can do this:

    try { ...
    } catch (IOException e) {
        throw unchecked(e);
    }

And the original exception is thrown without being wrapped. It's as though you had `throws IOException` on your method signature.

This is from my original solution to the problem: https://github.com/rogerkeays/jamaica-core/blob/0cc98b114998...

... not sure if serious or not

I put Java's popularity down to good support for Corporate-Oriented Programming ;)

You still get warnings about checked exceptions from this plugin, so it's not entirely flying blind.

I think this project shows how trivial it is to convert checked exception errors to compiler warnings.

https://github.com/rogerkeays/unchecked/blob/f22c8cde3557de0...

No need to change the type hierarchy. Just make it a compiler option.

Good point...

Ha, yeh. At first I had the command line examples first, but everyone was going on and on about maven and stuff, so I figured that's what the audience wants.

[EDIT] I moved the command line stuff back to the top of the README. XML makes my eyes bleed too...

The "what to do" and "tests" sections of this article is spot on! As for the sociopath/psychopath distinction, I think both terms refer to people with a Cluster B personality disorder. Since this is such a mouthful, I just call them predators, or if I don't want to scare people: vogons.

OK, sorry.

and a MyStringBuilderInterfaceProxyFactory too of course

The JDK team won't like this. As it is Fluent, Lombok, and (I presume) Manifold are using all sorts of unsupported hacks to access compiler internals. If you restrict yourself to the compiler plugin API you don't get much mileage.

sweet

IDEs are not my strong point. Aren't they smart enough to just search static methods in the scope of the compilation unit? Okay, so they have to be indexed first I suppose, but still... Ah, I suppose you want to search for methods you haven't imported yet. Now I get the annotation stuff. We're writing code for the IDE.

How do you do the same thing to java.lang.String?

Nice example. The extra parameters really drive the point home. Hope you don't mind if I steal it for the README.

I don't know yet. I'm already using some of my own variations of sneakyThrows, but what I really want is just to disable the whole damn thing in the compiler (checked exceptions are a compiler feature, not a JVM feature). I won't be changing the Java syntax though, sorry!

Yes, inheritance is a nightmare!

Fluent transforms the abstract syntax tree at compile-time resulting in .class'es in a .jar that always work at runtime. There are no runtime dependencies.

The syntax tree is only transformed when instance method lookup fails. i.e. when your code doesn't compile in standard java form. You would be doing pretty well to accidentally call an extension method seeing as you either have to write them or import them.

You can call a static method on an instance. This project allows you to call static methods not defined within the instance's class.

Do you really think a JEP is worth investing my time in? AFAICT, the Java gods have already made up their minds on extension methods.

Thanks for the link. I've been trying to find the canonical answer to this question myself. There's the philosophical standpoint: API designers should control their APIs, and the technical: poor reflective discoverability, poor discoverability through documentation, not overrideable, require ad-hoc conflict-management rules.

I like his use of the word should, because as we all know it really means won't. I should exercise more, I should stop trolling people on reddit. API designers should control their APIs.

As for the technical objections, I think the conflict-management rules hold the most weight, but this problem is no more difficult than any other in language design. "not overrideable" is a feature, not a bug (can we please give up on behavioural inheritance already?), and discoverability already sucks. I mean, I still use duckduckgo to find javadocs.

Just to make it clear, Fluent does not use any annotations.

Yeh, backwards compatibility is one of the biggest selling points of Java. Hopefully, Fluent will show that we can change one or two lines of compiler code and not burn down the whole house. We'll see.

Interesting. Do you need to put the extension method in a utility class at all though? Could we put it in the Main class in the example?

Also, creating a subclass just to add extension methods is definitely boiler plate. Util classes too, though they are useful for packaging functions at least.