Is it a good idea to have an extension function wi...
# getting-started
m
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:
y
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
m
> 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 😅
@Youssef Shoaib [MOD] 👀
y
What I meant was basically something you'd get if you inlined your method into:
Copy code
fun <T> T.onNotify(handler: T.() -> Unit): ULong = Unit.onNotify { handler(this@onNotify) }
And cleaned up all the `Unit`s
👍 1
d
edit: Nevermind, I reread it and it does need T. Any reason not to just make it fun
GObject.onNotify
?