#49 adds extension functions module

[willbuck]

No description provided.

[morki]

@willbuck Nice, thank you very much :) Am i supposed to close PR #44 now?

[willbuck]

@morki I think that makes sense, yeah. Thank you for already doing so, and thank you for your contribution!

[graemerocher]

This looks like a good start but I think we need more documentation in the user guide and also I would restructure the extensions so that they are not all in io.micronaut.kotlin but instead in packages that relate to the classes they apply to. For example io.micronaut.kotlin.http.client for the http client extensions

As more extensions are built this kind of organization will become important IMO

[willbuck]

That's definitely doable @graemerocher , I will get on that!

[willbuck]

@damianw and @bram209 Interested in your ideas to improve this PR as well, feedback is welcome!

[jameskleeh]

Adding this module will add all of these dependencies on the runtime classpath of applications that use them. I don't think we can safely assume users want runtime, http-server, or http-client. What can be done to only enable the extensions if the dependency is present?

[willbuck]

I'm not super familiar with all the various gradle lifecycle configurations for dependencies; is there a alternative to implementation (and something corresponding in source?) to mark classes to be optionally loaded only if something they depend on is present? Perhaps that's possible, I'm not sure, but I don't think I've heard of such a thing.

Alternatively, I could separate the extensions for those modules into corresponding kotlin modules (like having a micronaut-runtime-kotlin-ext subproject, a micronaut-http-client-kotlin-ext subproject, etc).

[edrd-f]

is there a alternative to implementation (and something corresponding in source?) to mark classes to be optionally loaded only if something they depend on is present?

I think what you want is compileOnly. It will allow the code to compile but will not load these dependencies at runtime, allowing users to optionally include them on their project's dependencies. More info here.

[jameskleeh]

@edrd-f Yes, however I don't know how Kotlin handles extension classes for classes that aren't on the classpath. If it simply ignores them then great.

[edrd-f]

@jameskleeh did a test now. It compiles and at runtime behaves just like Java: NoClassDefFoundError, which makes sense since it's not possible to get an instance of the class prior to the extension call.

[bram209]

Will try to review soon

[morki]

Any progress here? :)

[morki]

@jameskleeh @willbuck is there anything blocking?

[willbuck]

@morki I've been assigned to working on other things lately, apologies for the late reply; I think the hangup was around making sure there was a way to not require runtime, http-server and http-client, as well as just awaiting review.

I've tried out something that might accomplish the former, but need to double check @edrd-f 's assertion that this will not damage dependent apps, and also confer w/ the team that the NoClassDefFound behavior is appropriate.

[edrd-f]

Hi @willbuck. Sorry for not giving more info on my previous comment.

Extension functions are compiled to static functions, receiving the instance of the extended type as first argument. So, for example:

Main.kt

fun String.removeSpaces(): String {
    return this.replace(" ", "")
}

Will produce a bytecode that when decompiled to Java looks like:

@Metadata(...)
public final class MainKt {
   @NotNull
   public static final String removeSpaces(@NotNull String $this$removeSpaces) {
      Intrinsics.checkParameterIsNotNull($this$removeSpaces, "$this$removeSpaces");
      return StringsKt.replace$default($this$removeSpaces, " ", "", false, 4, (Object)null);
   }
}

As you can see, it's a new class, not a modification of the original class' bytecode.

In this case, since the extended type is received as argument, if it's not present in the classpath at runtime, a NoClassDefFoundError will be thrown even before the extension function is called. This is the same behavior of Java in case the code depends on a type that's not defined in runtime.

[willbuck]

@edrd-f @morki @jameskleeh Did my latest commit address the primary concerns around merging this new module, so we can provide these extension functions to folks?

[morki]

@willbuck for me this is ok, but I didn't have any concerns, I would just love to use those functions, thank you very much for your work :)

[edrd-f]

Looks good to me. And by the way, great work!