AI DSL : Generic serialization support for Sealed classes and other primitives

[raulraja]

This Pull Request introduces support for serializing sealed classes in Kotlin Serialization. It does so by mapping function names to the serial names of descriptors and integrating them into the JSON object processed by Kotlin Serialization. This enhancement enables the sealed class serializer to correctly identify and handle the appropriate class.

Here's an example demonstrating the support for sealed classes:

package com.xebia.functional.xef.dsl

import com.xebia.functional.xef.AI
import kotlinx.serialization.Serializable

@Serializable
sealed class Response {

  @Serializable
  data class City(val name: String) : Response()

  @Serializable
  data class Country(val name: String) : Response()

  @Serializable
  data class Continent(val name: String) : Response()
}

suspend fun main() {
  val response = AI<Response>("Capital of France?")
  println(response) // This will print: City(name=Paris)
}

In this example, the Response sealed class has three subclasses: City, Country, and Continent. Depending on the question asked, the appropriate subclass is instantiated and serialized.

Additionally, the PR extends support to primitives and other types that are not wrapped in a JsonObject. Here's an example:

suspend fun main() {
  val two: Int = AI("What is 1 + 1?")
  val truth: Boolean = AI("Is the earth flat?")
  val name: String = AI("Hi AI, What is your name?")
  println(
    """
    |two: $two
    |truth: $truth
    |name: $name
    """.trimMargin()
  )
}

In this second example, simple types like Int, Boolean, and String are used. The AI function returns the appropriate type based on the question asked, demonstrating the flexibility and utility of the new serialization support.

[raulraja]

This addition supports polymorphic types like sealed classes whose serializer is chosen by the type property, the discriminator.

[raulraja]

We also need the name to find the correct descriptor from the cases of the sealed class.

[raulraja]

Instead of tracking yes we track the actual function names

[raulraja]

This is a trick to support the spec supporting either String or a complex json object that specifies a function name.

[raulraja]

This can be an issue because we use simple function names without FQN. Sadly, sending the full package name to Open AI is not a good idea because selecting the proper function makes it more challenging. We bail if the function is not found in the cases, forcing the user to reencode it or provide @SerialName.

[Montagon]

It's great @raulraja!! 🔝