Is it a good idea to have an extension function with the signature of `fun <T : GObject> T.onN...

# getting-started

[Matyáš Vítek]

Is it a good idea to have an extension function with the signature of fun <T : GObject> T.onNotify(handler: T.() -> Unit): ULong like this as an extension function or would there be a way to make it better? The function is used for registering an event and it uses the instance which it is called on as a receiver. Whole implementation:

[Youssef Shoaib [MOD]]

Is it expected that the receiver could change? I'm not entirely sure how GObjects would work. If there isn't a reason to avoid holding a regular reference to the GObject, then I would suggest keeping it in a new lambda

[Matyáš Vítek]

> Is it expected that the receiver could change?
Do you mean like keeping the current lambda and calling the onNotify function with it on a different instance of GObject? If so, it's expected to happen just in some rare cases
> I'm not sure how `GObject`s would work
Right now, GObject is a wrapper for a base class in the GObject library
> If there isn't a reason to avoid holding a regular reference to the GObject, then I would suggest keeping it in a new lambda
Didn't really get what you mean by this 😅

[Matyáš Vítek]

@Youssef Shoaib [MOD] 👀

[Youssef Shoaib [MOD]]

What I meant was basically something you'd get if you inlined your method into:

fun <T> T.onNotify(handler: T.() -> Unit): ULong = Unit.onNotify { handler(this@onNotify) }

And cleaned up all the `Unit`s

[Daniel Pitts]

edit: Nevermind, I reread it and it does need T. Any reason not to just make it fun GObject.onNotify?