fork-handles / forkhandles Goto Github PK

What is the difference between Kotlin Value Classes and the Values4k approach?

Hi everyone,
I was stumbling upon this when trying to create a supposely simple data class. There is a Fabricator instance for every primitive type exception boolean in the library. Is it intentional that there is none for boolean? Adding something like

class BooleanFabricator(private val random: Random = Random) : Fabricator<Boolean> {
    override fun invoke() = random.nextBoolean()
}

should be easy enough. Therefore I wonder is this was intentionally omitted.
Cheers,
Ronny

The KSUID is the K-Sortable UID. It's meant to be a URL-safe identifier with an embedded timestamp and large random space.

https://segment.com/blog/a-brief-history-of-the-uuid/

https://github.com/segmentio/ksuid

I find it very useful. Would you be interested in adopting it into values4k? The intention is for the KSUID library to be a compile-only dependency. The value and its factory would require you to bring in your version of the library.

Sometimes having a positional argument is useful.

For example: cp [options] source_file target_file

The source file and target file are positional arguments. It's not set by following a flag, but by its position.

Fails with an infinite loop..

@Test
fun canExecuteCommandsThatRepeatWithFixedDelay_bug() {
    scheduler.scheduleWithFixedDelay(commandA, 2L, 3L, SECONDS)
    scheduler.scheduleWithFixedDelay(commandB, 2L, 3L, SECONDS)

    scheduler.tick(8L, SECONDS)

    assertEquals(listOf(commandA, commandA, commandA), invoked)
}

Hello !

I was wondering, what is the purpose of forcing the message ?

Why not let the client decide what to do with exceptions ?

In my case, I want to throw exceptions in the init of the class, by giving meaningful descriptions. Unfortunately, it gets messed up by this forced behavior.

Current situation

Given this code that fails (because YearMonth is not supported, see Additional comments) :

    data class Foobar(
        val z: YearMonth
    )

    @Test
    fun `supports YearMonth`() {
        assertThat(Fabrikate().random<Foobar>().also(::println), present())
    }

The returned error does not contain too much information about why it failed:

Proposed change

Modify InstanceFabricator to provide an exception similar to this:

Additional comments

This issue only focuses on the error handling. Supporting YearMonth would be interesting, but perhaps I will propose it in a different issue .

Hey there,

I've updated from 2.2.0.0 to 2.3.0.0 and am running into the exception dev.forkhandles.fabrikate.InstanceFabricator$NoUsableConstructor when trying to use Fabrikate().random<XXX>() on any self-written class in the whole project. Are there any changes I need to make to the code after updating the version? What could be the causes if nothing changed codewise? Also what info do you need from me to tackle this?

Thanks!

Any interest in adding value classes for common bases, i.e. 16, 32, 36, 64? They have applications not only in encoding binary, but also for setting easily understood constraints on identifiers. All of these values can be built with the existing tools, but it might be nice to have additional shortcuts.

However, there's no single proper way to handle out-of-bound characters; rather than reject the entire string, the developer may choose to have the invalid characters stripped, or coerced (in some cases). Making a single decision on which strategy to use might disqualify the value for many use-cases, but supporting multiple cases with options may be more than we want to handle in this library. Thoughts?

Example: For a base16/36 value, the developer may choose to coerce to uppercase
Example: For a MAC address, the developer may choose to strip the colon separators to coerce it to base16

Current status

Nullable properties are randomly set to null using the config Random:

 fun makeRandomInstance(classRef: KClass<*>, type: KType): Any? =
        when {
            type.isMarkedNullable && config.random.nextBoolean() -> null

Proposed change

Allow to make this configurable:

• Current behaviour (default): randomly set to null.
• Always set to null.
• Never set to null.

object MinimalCalculator {
    val cache = OutputCache<BigDecimal>()
    fun binaryExpr(s: String) = inOrder(ref { expr }, token(s), ref { expr })

    val number = oneOrMore(oneOf('0'..'9')).map { it.joinToString("").toBigDecimal() }.with(cache)
}

why not add getValue(k, p, self) for OutputCache:

class OutputCacheBy<out T>(private val p: Parser<T>) {
  fun getValue(k: KClass<*>, p: KProperty<*>, self: OutputCache) = p.with(self)
}

and then:

object MinimalCalculator {
    val cache = OutputCache<BigDecimal>()
    fun binaryExpr(s: String) = inOrder(ref { expr }, token(s), ref { expr })

    val number = by cache { oneOrMore(oneOf('0'..'9')).map { it.joinToString("").toBigDecimal() } }
}

Eh... looks ugly, but in real projects, I think p.with(cache) should have a shorter expression (maybe with a CachedParsers baseclass ext-fun?).

Hello there. I've recently decided to migrate one of my projects from Arrow to Result4k as all I really need is a Result type. The one thing I miss though are Kotest matchers like shouldBeInvalid, shouldBeValid, shouldBeLeft etc. and I couldn't find anything out of the box for Result4k!

Would this project be interested in a Kotest module? I've made a draft one here under the Result4k folder which provides various shouldBeSuccess and shouldBeFailure functions, usage looks like:

fun exampleDivideByZero() {
    val result = divide(5, 0) //function that returns Failure upon divide by zero

    //all of these would pass
    result.shouldBeFailure()
    result shouldBeFailure DivideByZeroFailure
    result shouldBeFailure { reason ->
        reason shouldBe DivideByZeroFailure
    }

    //but this will fail with the appropriate message
    result shouldBeSuccess 5 //Throws AssertionError like: Failure(DivideByZero) should be Success(5)
}

If you'd rather keep stuff like this out of this repo I'd be happy to just maintain this in a separate repo as it's pretty small in scope 😅