I Believe Zig Has Function Colors

Re:I Believe Zig Has Function Colors by int_19h on Saturday April 09, 2022 @05:00PM (#30972003)

The biggest problem with Java checked exceptions was that you couldn't generalize over them. Simply put, you can't write a method in Java that takes some object X, invokes X.Y(), and throws the same checked exceptions that X.Y() throws. This despite the fact that OO design is heavy on such equivalents of higher-order functions (think comparators, observers, visitors etc).

In a similar vein, as another commenter above said, really the only problem with function coloring is that we're not treating it polymorphically.

[ Parent | on HN ]

Re:I Believe Zig Has Function Colors by delusional on Saturday April 09, 2022 @07:29PM (#30973142)

Can't you though? I'm pretty sure you can

    public class SomeClass<E extends Exception> {
        public someMethod() throws E {}
    }

is valid java, I'm pretty sure.

[ Parent | on HN ]

Re:I Believe Zig Has Function Colors by int_19h on Sunday April 10, 2022 @12:45AM (#30974538)

It is valid Java, but this code lets you specify only a single exception type, while exception specifications can (and usually do) have multiple types. And Java doesn't have the equivalent of C++ template parameter packs.

The other problem with this approach is that it requires the caller to explicitly specify all the exceptions thrown by the function/object being wrapped. So every time you do map() or fold(), you have to spell out the full exception spec for the closure you're passing in. And god help you if there's nested maps...

[ Parent | on HN ]

Re:I Believe Zig Has Function Colors by int_19h on Sunday April 10, 2022 @04:53PM (#30981615)

BTW, the original structurally-typed proposal for closures in Java included generic exception specifications (among many other things). Unfortunately, that was killed off in favor of a much simpler take.

http://javac.info/closures-v06a.html

[ Parent | on HN ]