Hi all, How to check if a method is empty? Exampl...

# android

[Abhimanyu]

Hi all,
How to check if a method is empty?

Example,

interface TestInterface {
  fun emptyDefaultMethod() {}
}

fun TestComponent(
  impl: TestInterface,
) {
  if (impl == {} ) { // This doesn't work
    // Do something
  } else {
    // Do something else
  }
}

Usage without override for emptyDefaultMethod

TestComponent(object: TestInterface {})

Usage with override for emptyDefaultMethod

TestComponent(object: TestInterface {
  override fun emptyDefaultMethod {
    // Non empty override logic
  }
})

[Matthew Feinberg]

I don't think there's any good safe way to do that.

You could possibly (though I would NOT recommend it) make it work with something like:

val EMPTY_METHOD : ()->Unit = {}
interface TestInterface {
    val myMethod: ()->Unit = EMPTY_METHOD
}
fun TestComponent(
  impl: TestInterface,
) {
  if (impl.myMethod === EMPTY_METHOD ) {
    // Do something
  } else {
    // Do something else
  }
}
TestComponent(object: TestInterface {})
TestComponent(object: TestInterface {
    override val myMethod: ()->Unit get = {
        // Do something
    }
})

But.... there are SO many possible pitfalls to doing it this way, I'd be extremely wary of using it in production code.

You might also be able to do something with reflection to check if the method has been overridden or not (you probably won't be able to tell if it's empty or not though, just if it's been overridden). I'm not familiar enough with reflection on default implementations in interfaces...

But even that, I'd be super cautious about that in production code.

It might be better if you give some context about why you want do it and maybe someone might have a better (more idiomatic?) solution to suggest that doesn't involve checking if the method is empty or not.

(Also: Not sure this belongs in #android... it seems more like a general Kotlin question...)

[Abhimanyu]

Thanks @Matthew Feinberg for sharing.

I also ended up doing something very similar. (Changed the method to lambda variable, with default as null)

interface TestInterface {
  val customSlot: @Composable (() -> Unit)? 
    get() = null
}

fun TestComponent(
  impl: TestInterface,
) {
  if (impl.customSlot == null ) {
    // Do something
  } else {
    // Do something else
  }
}

Usage without override for emptyDefaultMethod

TestComponent(object: TestInterface {})

Usage with override for emptyDefaultMethod

TestComponent(object: TestInterface {
  override val customSlot = @Composable {
    // Slot code
  }
})

[Abhimanyu]

To share context,

I want to get some composables passed on from an app to a component (in a separate library).
As the component evolves, we may need to add additional composable slots.

First approach would be to deprecate the existing component and create new ones to maintain backward compatibility.
But, this would eventually lead to multiple versions of a component.

So, I was exploring ways in which I can add new slots to the component in the library without breaking the clients usages. (In a backwards compatible way)

[Abhimanyu]

I have been testing for last few hours, and did not find any major issues so far.

If you could share any possible issues that can happen, I would really appreciate it. thank you color

[Matthew Feinberg]

I don't think there's any guarantee that the compiler won't optimize it in some way where the comparison fails on some platforms... (I don't know enough about that to be sure, but it's a behavior I'd be hesitant to rely on).

[Matthew Feinberg]

Are you looking for backwards compatibility at a source level or binary level? At a source level, you could just use default arguments...

[Abhimanyu]

The app and library are all specific to android context.

fails on some platforms

Does this refer to platforms other than android?

[Abhimanyu]

Both, we are looking for API and ABI stability.

[Matthew Feinberg]

It would probably be stable in the JVM, I'd imagine, but it doesn't feel very idiomatic to me. Why not just use function overloads?

Something like this...

First version...

@Composable
fun MyComponent(
    firstSlot: @Composable ()->Unit = {} 
) {
   // Single common implementation here
}

Added slot:

@Composable
fun MyComponent(
    firstSlot: @Composable ()->Unit = {},
    secondSlot: @Composable ()->Unit = {} 
) {
   // Single common implementation here
}

// For backwards compatibility
@Composable
fun MyComponent(
    firstSlot: @Composable ()->Unit = {} 
) = MyComponent( firstSlot = firstSlot, secondSlot = {} )

[Matthew Feinberg]

You wouldn't need multiple versions; you'd just delegate simpler overloads to a common implementation.

[Matthew Feinberg]

(edited sample code to clarify that)

[Matthew Feinberg]

If you need to detect if a slot is used or not, you could make them nullable...

@Composable
fun MyComponent(
    firstSlot: (@Composable ()->Unit)? = null,
    secondSlot: (@Composable ()->Unit)? = null  
) {
   // Single common implementation here
   if( firstSlot == null ) {
   } else {
   }
}

// For backwards compatibility
@Composable
fun MyComponent(
    firstSlot: (@Composable ()->Unit)? = null 
) = MyComponent( firstSlot = firstSlot, secondSlot = null )

[Abhimanyu]

In our case,
The composable slots are not directly passed as parameters to the components.

Custom slot

interface ComponentSlots {
  // Some slots
}

Usage

Component(
  data = ComponentDataClass(),
  eventHandler = {},
  customSlots = object: ComponentCustomSlots {},
)

Adding new slot

interface ComponentSlots {
  // Some slots
  val slot1: @Composable (() -> Unit)? 
    get() = null
}

usage

Component(
  data = ComponentDataClass(),
  eventHandler = {},
  customSlots = object: ComponentCustomSlots {
    override val slot1 = @Composable {
      // Slot 1 code
    }
  },
)

[Abhimanyu]

So, function overload might not help us.

Reasoning for such complex logic.
Client can have trailing lambdas. So adding parameter in between the list of parameters breaks either the API or the ABI.

[Matthew Feinberg]

Hmm... I might be wrong, but I don't think adding methods to interfaces is ABI compatible on the JVM target, even with default method implementations.

[Abhimanyu]

Assuming I am now working with the variable using a lambda instead of a method directly, is that still the same?

[Abhimanyu]

Like this,
https://kotlinlang.slack.com/archives/C0B8M7BUY/p1711969877908879?thread_ts=1711943324.072489&cid=C0B8M7BUY

[Matthew Feinberg]

I think that's still the same, yes.

[Matthew Feinberg]

So if I understand correctly, the reason for not using parameters is because of the risk of the interpretation of a trailing lambda changing?

[Matthew Feinberg]

You can prevent trailing lambda by putting a vararg parameter at the end. Use a class with a private constructor for the type.

fun MyComponent(slotOne: ()->Unit = {}, slotTwo: ()->Unit = {}, vararg unused: NO_TRAILING_LAMBDA) {

}

[Matthew Feinberg]

class NO_TRAILING_LAMBDA private constructor()

[Matthew Feinberg]

Anything after the vararg must be a named parameter. A trailing lambda is a compile error.

[Abhimanyu]

Example

fun Component1(
  slot1: @Composable: () -> Unit
) {}

Usage

Component1 {
}

Adding new Slot

fun Component1(
  slot1: @Composable: () -> Unit
  slot2: @Composable: () -> Unit
) {}

breaks component1 existing usage.

[Abhimanyu]

The vararg things looks like a nice idea.
Thanks, let me explore more on that. gratitude thank you

[Matthew Feinberg]

No problem 🙂 I wish I could take credit, but learned it from looking at the Compose Multiplatform source code.