4 ms·

Extension methods to the rescue: https://en.wikipedia.org/wiki/Extension_method https://en.wikipedia.org/wiki/Extension_method Examples: https://kotlinlang.or

by esafak 2y ago

Extension methods to the rescue: https://en.wikipedia.org/wiki/Extension_method https://en.wikipedia.org/wiki/Extension_method Examples: https://kotlinlang.org/docs/extensions.html https://kotlinlang.org/docs/extensions.html https://docs.scala-lang.org/scala3/reference/contextual/extension-methods.html https://docs.scala-lang.org/scala3/reference/contextual/exte... See also: https://en.wikipedia.org/wiki/Uniform_function_call_syntax https://en.wikipedia.org/wiki/Uniform_function_call_syntax

vips7L 2y ago
I really wish you couldn't write extensions on nullable types. It's confusing to be able to call what look like instance functions on something clearly nullable without checking. fun main() { val s: String? = null println(s.isS()) // false } fun String?.isS() = "s" == this
- usrusr 2y ago
  The difference between .let{} and ?.let{} has great utility. You'd either have to give that up or promote let from regular code in the standard library to magic language feature. And you'd lose all those cases of extension methods where the convenience of accepting null left of the dot is their sole reason to be. Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Kotlin is about making peace with null, instead of pretending that null does not exist. (yes, I'm looking at you, Scala) What I do agree with is that extension methods should be a last ditch solution. I'd actually like to see a way to do the nullable receiver thing defined more like regular functions. Perhaps something like fun? name() = if (this==null) "(Absent)" else this.name that is defined inside the regular class block, imported like a regular method (as part of the class) and even present in the class object e.g. for reflection on the non-null case (and for Java compat where that still matters)
  - mrkeen 2y ago
    > Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Agreed. It should be a first-class construct in a language with its own own proper type, Null null; rather than needing to hitch a ride with the Integers and Strings like a second-class construct.
  - vips7L 2y ago
    Personally I find ?.let et al to be terrible for readability; most of the time you're better off doing a standard != null check. The same with nullable extension functions; they hurt readability. > Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Kotlin is about making peace with null, instead of pretending that null does not exist. (yes, I'm looking at you, Scala) I honestly find this to be such a weird thing to say or imply. No one is "scared" of null.
rikthevik 2y ago
Came here for the Uniform function call syntax link. This is one of the little choices that has a big impact on a language! I love it! I wrote a little pipeline macro in https://nim-lang.org/ https://nim-lang.org/ for Advent of Code years ago and as far as I know it worked okay. ``` import macros macro `|>`\* (left, right : expr): expr = result = newNimNode(nnkCall) case right.kind of nnkCall: result.add(right[0]) result.add(left) for i in 1..<right.len: result.add(right[i]) else: error("Unsupported node type") ``` Makes me want to go write more nim.

by esafak 2y ago

vips7L 2y ago

I really wish you couldn't write extensions on nullable types. It's confusing to be able to call what look like instance functions on something clearly nullable without checking. fun main() { val s: String? = null println(s.isS()) // false } fun String?.isS() = "s" == this

usrusr 2y ago
The difference between .let{} and ?.let{} has great utility. You'd either have to give that up or promote let from regular code in the standard library to magic language feature. And you'd lose all those cases of extension methods where the convenience of accepting null left of the dot is their sole reason to be. Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Kotlin is about making peace with null, instead of pretending that null does not exist. (yes, I'm looking at you, Scala) What I do agree with is that extension methods should be a last ditch solution. I'd actually like to see a way to do the nullable receiver thing defined more like regular functions. Perhaps something like fun? name() = if (this==null) "(Absent)" else this.name that is defined inside the regular class block, imported like a regular method (as part of the class) and even present in the class object e.g. for reflection on the non-null case (and for Java compat where that still matters)
- mrkeen 2y ago
  > Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Agreed. It should be a first-class construct in a language with its own own proper type, Null null; rather than needing to hitch a ride with the Integers and Strings like a second-class construct.
- vips7L 2y ago
  Personally I find ?.let et al to be terrible for readability; most of the time you're better off doing a standard != null check. The same with nullable extension functions; they hurt readability. > Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Kotlin is about making peace with null, instead of pretending that null does not exist. (yes, I'm looking at you, Scala) I honestly find this to be such a weird thing to say or imply. No one is "scared" of null.

rikthevik 2y ago

Came here for the Uniform function call syntax link. This is one of the little choices that has a big impact on a language! I love it! I wrote a little pipeline macro in https://nim-lang.org/ https://nim-lang.org/ for Advent of Code years ago and as far as I know it worked okay. ``` import macros macro `|>`\* (left, right : expr): expr = result = newNimNode(nnkCall) case right.kind of nnkCall: result.add(right[0]) result.add(left) for i in 1..<right.len: result.add(right[i]) else: error("Unsupported node type") ``` Makes me want to go write more nim.