First they came for the particles (electron, gluon, atom) now they are coming for mathematical constructs and give them mundane everyday meaning .
Or car parts, who can tell...
Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
41–44 of 44 posts
Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#42Wow, this looks like a god-send. The @Jailbreak annotation would give mid-2000's Java coders a heart-attack :) The only contentious point I find is that they are basically replicating Project Lombok's @SneakyThrows annotation via "Xplugin:Manifold stringsexceptions" or ModelMapper in their Structural Typing. Furthermore it seems it should be structured in sub-projects, eg. the String-templates and ManTL in one lib, S…
Thanks! The 'exceptions' option is quite a bit different from SneakyThrows. The 'exceptions' option completely mutes checked exceptions in your project -- you don't have to declare a throws clause or catch a checked exception anywhere in your code, thus with the option enabled checked exceptions behave exactly as unchecked exceptions. This behavior is identical to exception treatment in other JVM languages such as Sc…
My god, I just read a bit more about the Extension Manifold, and that is crazy good. I am doing both Java and JS, and I started to like duck-typing and extending prototypes so much in some situations. Now, Extensions give me something similar in Java?
I have the highest respect for your work, and no idea how you are doing that more or less on your own. I am just a bit sad your upcoming SQL/DDL extensions are going to kill one of my side-projects :) https://github.com/iSnow/sqlWebservice - if you can use a SQL schema as a type provider, you are leaps and bounds ahead of what I am doing there.
So, hats off, great job.
Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#43Manifold is an amazing piece of engineering. Scott McKinney, the author, used to work on Gosu but mostly focuses on this now. He added GraphQL support a few weeks ago: https://github.com/manifold-systems/manifold-sample-graphql-... You can just drop graphql files in your resources directory and start coding against them as type-safe interfaces immediately, no code-gen required. The @Jailbreak annotation is awesome to…
Looks pretty cool. Reminds me a lot of the ways in which Groovy improves Java.
Apache Groovy really improved on Beanshell (by adding closures, in 2003), which is what improved on Java (by adding dynamic typing, in late 1990's).
Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#44Earlier quoted context omitted.
No less safe until it the code is running in production on a Tuesday at 3AM and a library pukes up an exception it has never thrown before and your code doesn't handle it. I prefer exceptions to be declared, just like types. Having exceptions declared gives me more information about the operation of the code I am calling and that is useful. To treat exception declarations just as annoyance seems like lazy punting.
Likely you don't care which exception is thrown, only that one is. In that case, it's overkill to add the exceptions to the type signature. You'd be far likely to be better off using IO from Kotlin or IO[_] from Scala to model computations with exceptions as side-effects. Besides, any non-trivial method that calls any set of libraries/frameworks would need to declare tens or hundreds of checked exceptions in your sce…
that same 10s or 100s is true for error returns as well. what do you do with those?
convert it to internal types at the point you're exposed to them, then handle them in common ways. or re-throw as a general runtime exception if you don't have a way to handle it in your application. the difference with checked exceptions is that you have a correct, complete list of error scenarios that a library expects you to handle, and they provide a relatively easy way to defer handling.
there's no need for your `public static void main` to inherit all 100+ exception classes that your application is exposed to - that's just plain bad encapsulation.
---
granted, none of this touches on some of java's implementation issues, which essentially suffers from a lack of generics. e.g. you can't build an executor-framework without `raises Exception` or wrapping all errors in an internal wrapper, which loses compile-time safety. typed-exceptions-as-returns (i.e. typed result enums) keeps them within the normal type system, which does have some benefits for sure, but that ship has sailed. few languages are able to force exhaustive error handling at all, java's in a middle-ground with pros and cons.