@gildor commented on @Yogi’s file : @stepango

The Kotlin documentation says about delegates:

Property delegates don’t have to implement any interface, but they have to provide a getValue() function (and setValue() — for var's).

Why didn't they make it a requirement to implement the interface? Why do they have this one case of duck-typing, while the rest of the language requires implementing interfaces?

They do actually have interfaces for it, ReadOnlyProperty and ReadWriteProperty.

It's actually not the only case. Every type that has an

iterator()

method that returns an iterator can be used in a

for

loop. This is the reason you can use

Sequences

in a

for

loop

I think the reason an interface is not required is so that the requirement can be satisfied by an extension function. E.g. you can do

for (i in iterator)

because there is an extension function

fun Iterator.iterator() = this

The same applies to delegates. You can have an extension function

getValue

and it will work for delegates, too

Take for example delegating a property to a map. The Map itself doesn't implement any of ReadOnlyProperty/ReadWriteProperty interfaces and the required operators are implemented as extensions.

@kirillrakhman @ilya.gorbunov I see, thanks.

Is it a bad idea to write a delegate that caches the result of an expensive operation on the property name internally? The problem is then that instances can only be used once, I don't know if that's bad though.

This requires global state, right?

@karelpeeters https://github.com/MarioAriasC/funKTionale/blob/master/funktionale-memoization/src/main/kotlin/org/funktionale/memoization/namespace.kt#L21 by @dh44t can memoize results of expensive computations on any function. It's a common optimization technique used in FP. Not sure there is a need for delegates or object encapsulation beyond that unless you want to share results between different functions.

@kirillrakhman Well not really global, I could just keep it in the delegate instance

@raulraja Well I want to use delegates to make the interface of my class more fluent, but the problem is that it would require me to keep some state in the delegate. I'll probably fall back to memoization if nothing else works, thanks.

@borisdamato Maybe try asking one of those groups? But I'd be really surprised if you got a free licence from Jetbrains.

@borisdamato Unless Jetbrains owns Meetup.com I do not see how you can expect them to pay for your subscription when meetup.com is your choice. I'm sure there are free alternatives.

How should I be doing this?

private val messages = HashMap<LocalizablePlugin, Map<Array<Any>, Message>>()

    internal fun getMessageKeys(localizablePlugin: LocalizablePlugin): Set<Array<Any>> {
        if (!messages.containsKey(localizablePlugin)) {
            throw IllegalArgumentException("Provider has no registered messages.")
        }
        return messages[localizablePlugin].keys
    }

the return statement has an error: only safe or non-null asserted calls are allowed

Ha okay I was worrying I missed something @vaskir 😃

🙂 I'm a complete newbie

@dumptruckman handy too - if you need to do more than one statement you can also use run https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/run.html with the elvis operator (or anywhere an expression is expected), it's inline too so return behaves as if no extra function body

Asked on IRC but I figure slack is busier, relatively new to Kotlin (a week or so) I'm starting to play with modelling my domain in kotlin.. What are the potential pitful of the two approaches L30-39 (non type generics) vs L40-48 (using type generics) https://gist.github.com/sitepodmatt/87d7c43b9c3a3e07576db3b4e85eb429#file-kata-kt-L30

I don't really get your question. The difference is that the second one generic and thus potentially more general/more type-safe.

@karelpeeters Both achieve the same goals as far as I can see in my limited knowledge, i.e. both implement IntfResource, if I'm to add several resources which style is more favourable

How is the second one more type-safe, can you elaborate on that please, as I cant invariants being violated any less here than in first.

Okay let's say you have an instance of

Resource

, and you want to get the list of conditions from it. In the first case you'd get a

List<ResourceCondition>

. Maybe that's enough for you, but maybe you actually want/need to know what kind of conditions they are. The second case allows for this, you can have an instance of

AltResource<MyCondition>

, and you could get a list from it with type

List<MyCondition>

, allowing you to invoke

MyCondition

-specific behaviour.

But maybe you don't need to know they are `MyCondition`s, in which case you don't need generics at all and you can go with the first case.

Anyone else noticed that 1.1.3 IntelliJ plugin chokes on kotlinx.html library? Stuck on 1.1.2 plugin.

If you encounter the same, I would appreciate a vote here: https://youtrack.jetbrains.com/issue/KT-18653

Can methods like

String.isNullOrBlank

smart cast to not null? For instance, the following function won't compile:

class Test(val name: String?)

fun test(test: Test): String {
  val name = test.name
  if(name.isNullOrBlank()) {
    "null or blank"
  }
  else {
    name
  }
}

@eygraber No, probably because the compiler can't be 100% sure that method guarantees that name isn't null, because the runtime implementation could theoretically be different from the one the compiler can see. (this isn't the case, it's an inline function) A quick fix would be to add another null check:

var a: String? = "hey"

var b: String =
if (a.isNullOrEmpty() || a == null) {
    "empty"
}
else {
    a
}