Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
31–40 of 44 posts
Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#32Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#33Earlier 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.
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
#34Earlier 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.
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
#35Earlier 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!
Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#36At that point, why not just use another jvm language with these features like Kotlin?
or Scala https://www.scala-lang.org/
Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#37How 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.
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
#38I like the Extensions option. It works very much like D's UFCS mechanism.
Re: Manifold: Java Type-Safe Metaprogramming, Structural Typing, Extension Methods
#39Wow, 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…
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
#40Earlier 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.
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?