Access a shadowed receiver - kotlin

I would like to combine a Kotlin extension function on some receiver class Receiver with arrow-kt's either comprehension. In a regular Kotlin extension function, this binds to the receiver object; however, the either-comprehension EitherEffect shadows the Receiver this:
suspend fun Receiver.myFun(param: String): Either<Throwable, String> = either {
this.someMethod(...).bind() // Cannot access Receiver.someMethod, <this> is bound to EitherEffect
...
}
How can I access the receiver context within arrow's either-comprehension block (or any other monadic comprehension block)?

This is an issue inherited from Kotlin, but you can always access outer scoped this by referencing it by name. Here you can access Receiver by referencing it by this#myFun.
suspend fun Receiver.myFun(param: String): Either<Throwable, String> = either {
this#myFun.someMethod(...).bind() // Cannot access Receiver.someMethod, <this> is bound to EitherEffect
...
}
However, you should be able to simply call someMethod here without referencing this.
suspend fun Receiver.myFun(param: String): Either<Throwable, String> = either {
someMethod(...).bind()
...
}
Hope that solves your issue.

Related

How to create a member variable of Arrow Atomic in kotlin

Arrow-fx has a type Atomic which is similar to java AtomicRef but with an initial value, which means I don't need to check every time while accessing the atomic value whether it's null.
Here is a simple example
import arrow.fx.coroutines.*
suspend fun main() {
val count = Atomic(0)
(0 until 20_000).parTraverse {
count.update(Int::inc)
}
println(count.get())
}
Now I would like to create a class member variable with this type, but since it's only possible to initialize within a suspend function I would like to know the possibility here.
The easiest way is to make a "fake constructor" in the companion object.
public class Thingy private constructor(
val count: Atomic<Int>
) {
companion object {
suspend fun invoke() = Thingy(Atomic(0))
}
}
Now when you write Thingy(), you're actually calling the invoke function in Thingy.Companion. For that function there are no restrictions over suspending, so you can initialize Atomic as shown above.

Issue with function Overloading in kotlin

I am trying to declare two suspend methods with list of String and PublishRequest Object as parameter. But the IDE is giving error with this.
The error is either make one of the function internal or remove suspend. But i want to use coroutines inside both of them.
override suspend fun publish(publishRequests: List<PublishRequest>) {
///code
}
suspend fun publish(events: List<String>) {
///code
}
The PublishRequest Data class is internal. The issues is only coming when we add the publish(events: List) method. The code is working fine the publish(publishRequests: List)
Can you explain why it is happening ?
The problem you are facing is related to type erasure.
The types List<PublishRequest> and List<String> are erased to List<*>, as consequence, you would have a JVM signature clash.
To solve your problem you have two different solutions.
Change their names and avoid a signature clash:
suspend fun publishRequests(publishRequests: List<PublishRequest>) {}
suspend fun publishEvents(events: List<String>) {}
Use a single function with a reified type and handle the different type classes inside that function:
suspend inline fun <reified T> publish(objects: List<T>) {
when {
PublishRequest::class.java.isAssignableFrom(T::class.java) -> // it's a list of PublishRequest
T::class == String::class -> // it's a list of String
}
}

why there is 'by' for the extended class and reified in function define

coming across a sample with a class and a function and trying to understand the koltin syntax there,
what does this IMeta by dataItem do? looked at https://kotlinlang.org/docs/reference/classes.html#classes and dont see how to use by in the derived class
why the reified is required in the inline fun <reified T> getDataItem()? If someone could give a sample to explain the reified?
class DerivedStreamItem(private val dataItem: IMeta, private val dataType: String?) :
IMeta by dataItem {
override fun getType(): String = dataType ?: dataItem.getType()
fun getData(): DerivedData? = getDataItem()
private inline fun <reified T> getDataItem(): T? = if (dataItem is T) dataItem else null
}
for the reference, copied the related defines here:
interface IMeta {
fun getType() : String
fun getUUIDId() : String
fun getDataId(): String?
}
class DerivedData : IMeta {
override fun getType(): String {
return "" // stub
}
override fun getUUIDId(): String {
return "" // stub
}
override fun getDataId(): String? {
return "" // stub
}
}
why the reified is required in the inline fun <reified T> getDataItem()? If someone could give a sample to explain the reified?
There is some good documentation on reified type parameters, but I'll try to boil it down a bit.
The reified keyword in Kotlin is used to get around the fact that the JVM uses type erasure for generic. That means at runtime whenever you refer to a generic type, the JVM has no idea what the actual type is. It is a compile-time thing only. So that T in your example... the JVM has no idea what it means (without reification, which I'll explain).
You'll notice in your example that you are also using the inline keyword. That tells Kotlin that rather than call a function when you reference it, to just insert the body of the function inline. This can be more efficient in certain situations. So, if Kotlin is already going to be copying the body of our function at compile time, why not just copy the class that T represents as well? This is where reified is used. This tells Kotlin to refer to the actual concrete type of T, and only works with inline functions.
If you were to remove the reified keyword from your example, you would get an error: "Cannot check for instance of erased type: T". By reifying this, Kotlin knows what actual type T is, letting us do this comparison (and the resulting smart cast) safely.
(Since you are asking two questions, I'm going to answer them separately)
The by keyword in Kolin is used for delegation. There are two kinds of delegation:
1) Implementation by Delegation (sometimes called Class Delegation)
This allows you to implement an interface and delegate calls to that interface to a concrete object. This is helpful if you want to extend an interface but not implement every single part of it. For example, we can extend List by delegating to it, and allowing our caller to give us an implementation of List
class ExtendedList(someList: List) : List by someList {
// Override anything from List that you need
// All other calls that would resolve to the List interface are
// delegated to someList
}
2) Property Delegation
This allows you to do similar work, but with properties. My favorite example is lazy, which lets you lazily define a property. Nothing is created until you reference the property, and the result is cached for quicker access in the future.
From the Kotlin documentation:
val lazyValue: String by lazy {
println("computed!")
"Hello"
}

How to define an extension function for a companion object of a typealias?

I thought typealiases were the same as the original type, just a different name.
I figure typealiases have the same references as the original type.
typealias Celsius = Double
fun Double.Companion.foo() {} // Works
fun Celsius.Companion.foo() {} // Does not work
Here, Companion is accessible from Double but Celsius gives an unresolved reference error.
No, you can't access to the companion objects via typealias. One possible workaround to create one more typealias for concrete companion:
typealias CelsiusCompanion = Double.Companion
After that you can use it as following:
fun CelsiusCompanion.foo() {}
If you want to define an extension function, it is not possible as hluhovskyi already stated, but things are differently if you just want to invoke functions of a companion object.
There are two ways of accessing functions and properties within a companion object. You can either specify the access explicitely or implicitely. The implicit way works with a typealias the explicit one does not.
Consider this minimal example:
class ClassWithCompanion{
companion object {
fun sayHello() {
println("Hello")
}
}
}
typealias Alias = ClassWithCompanion
fun main(args: Array<String>) {
ClassWithCompanion.sayHello() // implicit
ClassWithCompanion.Companion.sayHello() // explicit
Alias.sayHello() // implicit (works)
Alias.Companion.test() // explicit (does not work)
}

How to reference "this" within anonymous listeners when using short notation?

In Kotlin, is there a way to reference the listener instance when using this short notation for anonymous classes? In this case this refers to outer context (e.g. the Activity instance) where view is defined:
view.setOnClickListener {
val self: View.OnClickListener = this // Not compiling, "this" references outer context
}
When using the longer notation where you explicitly state the interface to be implemented and where you explicitly override the callback method, the listener can be referenced through this:
view.setOnClickListener(object: View.OnClickListener {
override fun onClick(v: View) {
val self: View.OnClickListener = this // Ok
}
})
You can get that resolved by adding an #ActivityName in front of 'this' reference
For example if your Activity name was MainActivity the solution would be:
view.setOnClickListener {
val self: View.OnClickListener = this#MainActivity
}
The term short notation for anonymous classes is not entirely correct. It's actually a short notation for anonymous functions, i.e. lambdas. Of course under the hood they are compiled to classes but from a programming language point of view, anonymous functions don't have identities and therefore it doesn't make sense to refer to their instances via this.
val animation = object : Animation() {
override fun applyTransformation(interpolatedTime: Float, t: Transformation) {
val layoutParam: RelativeLayout.LayoutParams? = playerView.layoutParams as RelativeLayout.LayoutParams?
layoutParam?.topMargin = convertDpToPixel(position, this#SurahActivity).toInt()
playerView.layoutParams = layoutParam
}
}
Somewhat related - here is an example of removing a listener from the listener itself that came about after not being able to refer to itself as reported by the accepted answer
#Suppress("JoinDeclarationAndAssignment")
fun View.foo() {
// can't combine this with the assignment since it is referenced within the
// body of the layout listener to remove itself
lateinit var layoutListener: ViewTreeObserver.OnGlobalLayoutListener
layoutListener = ViewTreeObserver.OnGlobalLayoutListener {
// ... do something ...
viewTreeObserver.removeOnGlobalLayoutListener(layoutListener)
}
viewTreeObserver.addOnGlobalLayoutListener(layoutListener)
}
I don't typically see lateinit used in a local method field so this wasn't immediately obvious to me