Advanced Kotlin DSL: Building Smart Builders with Validation and Error Aggregation

Den B — Tue, 01 Apr 2025 09:03:27 +0000

Kotlin DSLs are often used for configuration or UI building, but they rarely enforce correctness at compile or runtime. You can enhance DSLs with declarative validation logic, using internal builder patterns to collect multiple errors at once—an uncommon but highly powerful pattern.

✅ Use Case: Validating a DSL for Form Submission Logic

Instead of failing fast on the first error, we want to collect all configuration errors and then fail with full diagnostics.

⚙️ DSL with Validation Support

@DslMarker
annotation class FormDsl

@FormDsl
class FormBuilder {
    private val errors = mutableListOf<String>()
    private var name: String? = null
    private var email: String? = null

    fun name(value: String) {
        if (value.isBlank()) errors += "Name cannot be blank"
        name = value
    }

    fun email(value: String) {
        if (!value.contains("@")) errors += "Invalid email format"
        email = value
    }

    fun build(): Form {
        if (errors.isNotEmpty()) {
            throw IllegalArgumentException("Form validation failed:\n" + errors.joinToString("\n"))
        }
        return Form(name!!, email!!)
    }
}

data class Form(val name: String, val email: String)

fun form(block: FormBuilder.() -> Unit): Form =
    FormBuilder().apply(block).build()

✅ Usage:

val form = form {
    name("")
    email("no-at-symbol")
}
// Throws with detailed error report:
// - Name cannot be blank
// - Invalid email format

📌 Notes for Quick Reference
• ✅ Use errors: MutableList to accumulate configuration mistakes.
• ✅ Use @DslMarker to prevent scope collisions.
• ❌ Avoid throwing inside individual DSL methods—defer until .build().
• ✅ Ideal for CI/CD DSLs, Terraform-style Kotlin config, or complex form builders.

🚀 Pro Tip: Add warning() support next to error() to flag non-blocking suggestions during DSL execution, mimicking compiler diagnostics.

Advanced Kotlin: Inline Reified Generics for Type-Safe Reflection and JSON Parsing

Den B — Tue, 01 Apr 2025 07:15:43 +0000

One of the most powerful yet underused features in Kotlin is the combination of inline + reified type parameters. This allows you to retain type information at runtime, enabling type-safe operations like JSON deserialization, dependency resolution, and reflection—without needing explicit Class objects.

✅ Real-World Problem: Generic JSON Parsing

In Java/Kotlin with Gson or Moshi:

inline fun <reified T> Gson.fromJson(json: String): T =
    this.fromJson(json, object : TypeToken<T>() {}.type)

🔍 Without reified, you’d have to pass Class explicitly, and lose type safety for generic types like List.

💡 Use Case: DSL or DI Framework

Suppose you’re writing a lightweight DI container or DSL:

inline fun <reified T> inject(): T {
    return container.resolve(T::class.java) as T
}

✅ No need to pass User::class.java — it’s inferred and reified at compile time.

🔥 Use Case: Type-Safe Routing or Serialization

inline fun <reified T> isTypeOf(value: Any): Boolean {
    return value is T
}

val result = isTypeOf<String>("test") // ✅ true
val result2 = isTypeOf<List<Int>>(listOf(1, 2, 3)) // ✅ true

📌 Notes for Quick Reference
• Use inline + reified when you want access to T::class, is T, or TypeToken().
• Great for JSON parsing, reflection utilities, and type-safe DSLs.
• Avoid using it in public API boundaries that must be compiled to Java—Java won’t understand reified generics.

🚀 Pro Tip: When writing coroutine-based network libraries or internal frameworks, use inline reified to make API usage cleaner and more intuitive—especially when dealing with typed responses.

DEV Community: Den B

Advanced Kotlin DSL: Building Smart Builders with Validation and Error Aggregation

Advanced Kotlin: Inline Reified Generics for Type-Safe Reflection and JSON Parsing