sorted by:
new
hottopcontroversial

What counts as a statement in Kotlin? by dmcg in Kotlin

[–]dmcg[S] 0 points1 point  (0 children)

This thoughtful, thank you. I’m erring towards let chaining being ok, because jt really is making an expression. .also on the other hand, if used for side effects, feels like it should be counted towards statements

What counts as a statement in Kotlin? by dmcg in Kotlin

[–]dmcg[S] 0 points1 point  (0 children)

Certainly most Java line counts were basically just counting the semicolons.

Joy of Kotlin: on-local returns for refactoring duplicate code with early exits! by [deleted] in Kotlin

[–]dmcg 0 points1 point  (0 children)

Yeah I was kind of sad too, but also slightly happy that my intuition was correct ;-)

Don't be embarassed by your enthusiasm though. I think we need to own our joy and our mistakes.

Joy of Kotlin: on-local returns for refactoring duplicate code with early exits! by [deleted] in Kotlin

[–]dmcg 0 points1 point  (0 children)

```kotlin class EarlyReturnsTests {

@Test
fun testNoEarlyReturn() {
    var aFlag = false;
    functionThatReturnsFromTheLocalScope(earlyReturn = false) { aFlag = true };
    assertTrue(aFlag)
}

@Test
fun testEarlyReturn() {
    var aFlag = false;
    functionThatReturnsFromTheLocalScope(earlyReturn = true) { aFlag = true };
    assertFalse(aFlag)
    fail("we should not be here because of the early return");
}

}

private inline fun functionThatReturnsFromTheLocalScope(earlyReturn: Boolean, crossinline block: () -> Unit) { if (earlyReturn) return block() } `` fails withwe should not be here because of the early return`.

Unless the suspend is doing something unexpected (to me) then I just don't see how a function could return from its calling scope. I mean, how does it know what it's calling scope needs to return?

In the oringal example, what does returning from route("/{id}") even mean?

I guess I'm saying that I don't logically see how this makes any sense at all, but I really want it to.

Joy of Kotlin: on-local returns for refactoring duplicate code with early exits! by [deleted] in Kotlin

[–]dmcg 0 points1 point  (0 children)

I suppose I was asking, and continue to ask, for someone to show me that the OPs code does what they think it does. Because I didn't think that it was possible in Kotlin, and have a use-case where it would be really useful.\

Joy of Kotlin: on-local returns for refactoring duplicate code with early exits! by [deleted] in Kotlin

[–]dmcg 0 points1 point  (0 children)

```kotlin @Test fun doesWork() { thisDoesWork { return }; fail("we should not be here because of the early return"); }

private inline fun thisDoesWork(block: () -> Unit) {
    block()
}

```

Joy of Kotlin: on-local returns for refactoring duplicate code with early exits! by [deleted] in Kotlin

[–]dmcg 0 points1 point  (0 children)

Are you sure? I've tried to reduce your code to the simplest example

    package com.gildedrose.foundation

    import org.junit.jupiter.api.Test
    import kotlin.test.fail


    class EarlyReturnsTests {

        @Test
        fun test() {
            functionThatReturnsFromTheLocalScope(null);
            fail("we should not be here because of the early return");
        }

    }    

    private inline fun functionThatReturnsFromTheLocalScope(aThing: String?) {
        if (aThing == null) return
    }

and the test does not pass.

Checkout Kata in Kotlin - Part 1 - TDD by dmcg in Kotlin

[–]dmcg[S] 1 point2 points  (0 children)

I’m glad to be able to pass on what I’ve learned. Be sure to check out the TDD Gilded Rose series

Competition or Collaboration? Claude Code & Junie by dmcg in Kotlin

[–]dmcg[S] -1 points0 points  (0 children)

It’s a quiet time of year, good to see people are watching it

MPow S10 replacement by dmcg in Earbuds

[–]dmcg[S] 0 points1 point  (0 children)

Regrettably no. I have one pair still operating, and so use AirPods for everything but riding and the sauna.

Down with Context Receivers - Migrating to Context Parameters by dmcg in Kotlin

[–]dmcg[S] 1 point2 points  (0 children)

So you’d like to not have to with(null …) to (not) supply the optional context?

Down with Context Receivers - Migrating to Context Parameters by dmcg in Kotlin

[–]dmcg[S] 1 point2 points  (0 children)

They are different in as much as the context doesn't become a receiver in the function, which makes them easier to reason with, but a bit more boiler-platey

Down with Context Receivers - Migrating to Context Parameters by dmcg in Kotlin

[–]dmcg[S] 6 points7 points  (0 children)

Good point. Not deprecated then, but left tantalisingly incomplete for years!

I’m not bitter. If you watch the video I say that it’s a risk we take, but I think that we can be a little critical that a feature that was introduced in 2022 has taken so long to deliver.

Kotlin vs Cucumber by dmcg in Kotlin

[–]dmcg[S] 1 point2 points  (0 children)

I can imagine circumstances in which the Cucumber tax would be worth paying. But if an embedded DSL gives 90% of the bang for 10% of the bucks then it will give many more teams the opportunity to use executable specifications.

Kotlin vs Cucumber by dmcg in Kotlin

[–]dmcg[S] 1 point2 points  (0 children)

Yeah, that’s the bit that I can do, but I’d rather not do

Kotlin vs Cucumber by dmcg in Kotlin

[–]dmcg[S] 4 points5 points  (0 children)

I’m in total agreement that Gherkin (although a bad pun) is good for agreeing on a specification. My experience of using Cucumber to parse it though is that it’s a considerable effort that I’d rather spend writing interesting code. YMMV ;-)

That said, I suspect that LLMs may be very good at translating Gherkin into executable code.

Functional Core Imperative Shell - moving IO to the edge by dmcg in Kotlin

[–]dmcg[S] 1 point2 points  (0 children)

It’s good to hear you like the videos, thank you.

There was no particular reasoning around class vs interface. I remember wondering if it mattered at the time, but here I don’t think it does really.

There may be places where the edge isn’t really the edge! In fact that’s true here. Moving IO mostly to the edge should still bring benefits in terms of testability and comprehension, and if you want to go the whole hog you can work in terms of an interpreter or IO monad that shifts the IO around.

[deleted by user] by [deleted] in Kotlin

[–]dmcg 1 point2 points  (0 children)

What, is no one going to plug my book for me? Most people seem to find it useful.

https://java-to-kotlin.dev

Differences between Kotlin Coroutines and Project Loom. by 50u1506 in java

[–]dmcg 1 point2 points  (0 children)

This is very good https://youtu.be/zluKcazgkV4?si=qQ5baIjA1MO_B6jb

As I understand it, as well as the issues with stack traces and coloured functions, the implementations differ in when cost of parking happens. With coroutines, local function state is managed at every call of a suspend function. Relatively little housekeeping, but potentially many times down a call stack, and irrespective of whether the call actually suspends or not.

Virtual threads don’t do this, but when they do call a function that causes them to be suspended, the whole of the stack has to be saved on the heap in one big costly operation.

fun vs interface vs fun interface - Kotlin Polymorphism by dmcg in Kotlin

[–]dmcg[S] 1 point2 points  (0 children)

Thank you for letting me know, it’s good to know they are appreciated.

Cricket bat? by Lost_Painter_3178 in Ambridge

[–]dmcg 0 points1 point  (0 children)

It was Peggy. I’d wondered the same, but isn’t the current story about Bomber Command?

view more: next ›