Live data from Hacker News

Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

github.com

31–40 of 44 posts

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#32

At that point, why not just use another jvm language with these features like Kotlin?

at that point why not use C#?

C# doesn’t support type providers, only f# supports them.

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#33
post #9

Earlier quoted context omitted.

It's optional. It seems scary, but checked exceptions are a feature exclusive to the Java compiler -- the JVM does not enforce them. This is how JVM languages like Kotlin and others only use unchecked exceptions, and also how Manifold gets away with muting them as a compile-time feature.

It should not be optional :) Checked exceptions is a stupid feature because it makes an implementation detail, the fact that a code raises an exception, part of the type of a method. Scala, C# or Kotlin have no checked exception and it doesn't make them less safe.

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.

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#34
post #9

Earlier quoted context omitted.

It's optional. It seems scary, but checked exceptions are a feature exclusive to the Java compiler -- the JVM does not enforce them. This is how JVM languages like Kotlin and others only use unchecked exceptions, and also how Manifold gets away with muting them as a compile-time feature.

It should not be optional :) Checked exceptions is a stupid feature because it makes an implementation detail, the fact that a code raises an exception, part of the type of a method. Scala, C# or Kotlin have no checked exception and it doesn't make them less safe.

The fact that a function can fail is not an implementation detail, it should be part of the signature of the method.

And if the method can suddenly fail in a new way, that signature should change so that callers of that method can adjust to the new failure case.

Checked exceptions force you to consider error cases, there's nothing stupid about them.

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#35
post #17

Earlier quoted context omitted.

Manifold hooks into the Java compiler via the javac plugin API. This is similar to the way annotation processors work, but without the overhead of additional passes (or rounds) in the compiler. The plugin route also provides access to earlier stages of the compiler, for example this is how Manifold's string interpolation feature works. The overall details are a bit deep and dark for a comment, however ;)

I've played with the compiler's API before and found it incredibly difficult to work with... and completely undocumented... how did you manage to get through that? Great job!

Thank you! After I got past the initial shock with the javac codebase (it's an unusual design) I came to appreciate it. Given it's age and the number of revisions it has undergone, it holds up pretty well. But, yeah, building Manifold required a bit of determination.

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#36
post #24

At that point, why not just use another jvm language with these features like Kotlin?

or Scala https://www.scala-lang.org/

Scala comes with a lot of overhead in terms of features (and breaking changes in versions) and is still missing the meta-programming aspect of this library. In fact, scala has now deprecated all it's previous attempts at meta-programming and is still trying to work out it's next attempt (which is I believe black-box only so can't do what this library does).

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#37

How is the user experience with that if you don't use Intellij? It seems to require explicit support by the IDE, which is why it doesn't seem to work with eclipse.

(Hi, I'm the author of Manifold) Manifold works equally well with Java 8 - 12. While no IDE is required, it is designed to fully leverage Java's static type system, which heavily benefits from the static analysis provided by a topnotch IDE like IntelliJ IDEA. Code completion, deterministic refactoring, usage searching, feature navigation, incremental compilation, etc. -- suddenly these productive features are now available to any resource connected with Manifold e.g, GraphQL, JSON Schema, Javascript, etc.

Re Intellij v. Eclipse. I'm just one guy banging on a project; I only have time to build and maintain one IDE plugin and right now my focus is on IntelliJ. I'd like to start working on an Eclipse plugin at some point... or trick someone else into doing the work ;)

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#39
post #27

Wow, 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 Scala, Kotlin, Ceylon, etc.

Regarding sub-projects on extensions, I've been meaning to do that. The project is already divided into separate targets e.g., manifold-graphql, manifold-json, etc. But manifold-ext has probably grown too big for one target.

Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods

#40
post #33

Earlier quoted context omitted.

It should not be optional :) Checked exceptions is a stupid feature because it makes an implementation detail, the fact that a code raises an exception, part of the type of a method. Scala, C# or Kotlin have no checked exception and it doesn't make them less safe.

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 scenario. And that's just the catchable exceptions. What are you going to do about any (subclass of) Error?

Post reply on HN