4 ms·

Nice, this is one of the features that makes using Kotlin with existing Java frameworks so nice. It can really cut down on the boiler plate Java is infamous for

Nice, this is one of the features that makes using Kotlin with existing Java frameworks so nice. It can really cut down on the boiler plate Java is infamous for. You can define extension functions on any type, or type alias. So anything that looks like it could be shorter or is a bit repetitive, you just define an extension function to make that go away.

MrBuddyCasino 3y ago
When you start transforming the AST, that might be a sign you should switch languages. Kotlin is nice, why not use it.
- rogerkeays 3y ago
  Kotlin is great, but it is a fairly heavy dependency if all you want is extension methods. Java has mostly caught up in many other aspects, so I'm experimenting with Java + one or two compiler hacks. Checked exceptions are my next target...
  - javanonymous 3y ago
    I'm curious about how you plan to work on checked exceptions. If it's just about ignoring forced exception management, Lombok provides the @SneakyThrows annotation. I would need something more before I add a new type of extension. Maybe if you could solve the null-check issue. i.e. rewriting var x = a.getFoo()?.getBar() to var x = a.getFoo() != null ? a.getFoo().getBar() : null In that case I may consider it for my personal projects, and then potentially recommend it at work once it becomes more widespread and has IDE support.
    - rogerkeays 3y ago
      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!
      - zeedude 3y ago
        I believe Manifold already does this. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-exceptions https://github.com/manifold-systems/manifold/tree/master/man...
        rogerkeays 3y ago
        sweet
- kaba0 3y ago
  I think Kotlin differs far too much from Java — I don’t want all those plus features that will inevitably branch too far from the JVM/Java corresponding code, becoming its new thing. I might want a nearly-Java language that only adds trivial syntax sugar, but are otherwise the same. Groovy sort of had a good initial idea here (being a superset of Java, though again, it has grown apart a bit since). For me Kotlin lives in this weird limbo between these two extremes. If I want a different language on the JVM I would rather do Scala or Clojure.
  - vips7L 3y ago
    For me, if Kotlin is on the table I might as just use C# where the entire ecosystem is built around these concepts.
    - kaba0 3y ago
      I wouldn’t really leave behind the JVM ecosystem, which is much bigger and better quality than the .NET one from what I gathered (though it is still good and bigger than most other languages’). And other people’s code is the numero uno productivity boost, so it’s an important area.
      - vips7L 3y ago
        I think I would be fine with a smaller ecosystem. I've seen a lot of projects that have made bad choices in libraries because there are too many. Sometimes I feel like if there was just one blessed jdk way it would be a lot simpler. Honestly, the only thing that is keeping me from .NET right now is async/await. Pron really did Java a service by pushing for virtual threads.
misja111 3y ago
How does this cut down on boilerplate? The examples given on the website seem equally long. assertNotEmpty(getHttpContent(createSharedUrl(website, "styles.css"))); vs website.createSharedUrl("styles.css").getHttpContent().assertNotEmpty();
- tuyiown 3y ago
  Typically, boiler plate implemented by a standalone function is not easily discoverable, eg. no clear convention where to put it, does not look idiomatic on some usages syntax habits, and not suggested by auto completion in top results. Extensions are searchable by syntax and naturally in a namespace, largely diminishing the risk of put it in in a single use function that will be quickly forgotten, and might seem obscure. The code itself might not be much shorter, but you don't introduce code looking weird, if it's re-usable it's now discoverable, and if your boilerplate contained a lot of micro adjustments on a larger glue code, this glue code is now shorter and way clearer.
  - rogerkeays 3y ago
    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.
    - kaba0 3y ago
      Subclassing may not always be possible (final class, or method) and can break class invariants. Util classes with helper methods and/or extension methods are not prone to these problems.
      - rogerkeays 3y ago
        Yes, inheritance is a nightmare!
  - misja111 3y ago
    > Extensions are searchable by syntax This would be very useful. But how are these extension methods more searchable by syntax than the 'old fashioned' static util methods? I admit I haven't tried, but I suspect that code completion in my IDE wouldn't include these extension methods.

MrBuddyCasino 3y ago

When you start transforming the AST, that might be a sign you should switch languages. Kotlin is nice, why not use it.

rogerkeays 3y ago
Kotlin is great, but it is a fairly heavy dependency if all you want is extension methods. Java has mostly caught up in many other aspects, so I'm experimenting with Java + one or two compiler hacks. Checked exceptions are my next target...
- javanonymous 3y ago
  I'm curious about how you plan to work on checked exceptions. If it's just about ignoring forced exception management, Lombok provides the @SneakyThrows annotation. I would need something more before I add a new type of extension. Maybe if you could solve the null-check issue. i.e. rewriting var x = a.getFoo()?.getBar() to var x = a.getFoo() != null ? a.getFoo().getBar() : null In that case I may consider it for my personal projects, and then potentially recommend it at work once it becomes more widespread and has IDE support.
  - rogerkeays 3y ago
    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!
    - zeedude 3y ago
      I believe Manifold already does this. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-exceptions https://github.com/manifold-systems/manifold/tree/master/man...
      - rogerkeays 3y ago
        sweet
kaba0 3y ago
I think Kotlin differs far too much from Java — I don’t want all those plus features that will inevitably branch too far from the JVM/Java corresponding code, becoming its new thing. I might want a nearly-Java language that only adds trivial syntax sugar, but are otherwise the same. Groovy sort of had a good initial idea here (being a superset of Java, though again, it has grown apart a bit since). For me Kotlin lives in this weird limbo between these two extremes. If I want a different language on the JVM I would rather do Scala or Clojure.
- vips7L 3y ago
  For me, if Kotlin is on the table I might as just use C# where the entire ecosystem is built around these concepts.
  - kaba0 3y ago
    I wouldn’t really leave behind the JVM ecosystem, which is much bigger and better quality than the .NET one from what I gathered (though it is still good and bigger than most other languages’). And other people’s code is the numero uno productivity boost, so it’s an important area.
    - vips7L 3y ago
      I think I would be fine with a smaller ecosystem. I've seen a lot of projects that have made bad choices in libraries because there are too many. Sometimes I feel like if there was just one blessed jdk way it would be a lot simpler. Honestly, the only thing that is keeping me from .NET right now is async/await. Pron really did Java a service by pushing for virtual threads.

misja111 3y ago

How does this cut down on boilerplate? The examples given on the website seem equally long. assertNotEmpty(getHttpContent(createSharedUrl(website, "styles.css"))); vs website.createSharedUrl("styles.css").getHttpContent().assertNotEmpty();

tuyiown 3y ago
Typically, boiler plate implemented by a standalone function is not easily discoverable, eg. no clear convention where to put it, does not look idiomatic on some usages syntax habits, and not suggested by auto completion in top results. Extensions are searchable by syntax and naturally in a namespace, largely diminishing the risk of put it in in a single use function that will be quickly forgotten, and might seem obscure. The code itself might not be much shorter, but you don't introduce code looking weird, if it's re-usable it's now discoverable, and if your boilerplate contained a lot of micro adjustments on a larger glue code, this glue code is now shorter and way clearer.
- rogerkeays 3y ago
  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.
  - kaba0 3y ago
    Subclassing may not always be possible (final class, or method) and can break class invariants. Util classes with helper methods and/or extension methods are not prone to these problems.
    - rogerkeays 3y ago
      Yes, inheritance is a nightmare!
- misja111 3y ago
  > Extensions are searchable by syntax This would be very useful. But how are these extension methods more searchable by syntax than the 'old fashioned' static util methods? I admit I haven't tried, but I suspect that code completion in my IDE wouldn't include these extension methods.