Consider the Traversable trait, for example. Given a single operation's implementation,

forEach

, you can derive a set of other common operations: Append (

++

),

map

,

copy

,

isEmpty

, etc.

This allows you to narrow the scope of your dependencies to the smallest set of functionality that makes sense for your current interface. Can any such narrowing of knowledge and scope be performed with any of Java's collections, or are you forcibly coupled to far stricter guarantees and implementation details than are desirable?

The Scala collections suffer from similar problems as the Java one, i.e. traits have an insane amount of methods that make it almost impossible to implement reasonably

certainly far from the standards set by the STL or other delegate based designs

I think Kotlin's decision to not have its own collection framework and use Java's instead is optimal at this time.

And overall, I think the benefits ascribed to using interfaces instead of concrete classes are more theoretical than practical. Sure, you could pass a LinekdList instead of an ArrayList to that function but the results will most likely be disastrous. In practice, having hints on the concrete instance you're getting passed is extremely important.

Actually, that's the interesting thing about traits. Their implementations can be derived simply by implementing a small set of methods. Once you know how to traverse a Traversable object, the other methods arrive for free, and you don't have to implement a single one. It's basically a more formal / closely bound version of extension methods, if you're looking at it from a Kotlin/.NET perspective.

hints on the concrete instance

That seems like a case where you need more specific interfaces. Even if they appear to have similar methods, you may be able to set different expectations between them, with implementations choosing the interfaces that they best fit. Though then you run into the issue with namespace collisions, etc. So it's not a perfect solution, either.

More specific interfaces can't always solve this. Technically,

LinkedList

is random access but practically, it's probably never the right thing to do.

It's the difference between an interface as a purely code contract and an interface as a conceptual contract. I'm curious as to whether we'll be able to find more formal methods for differentiating such implementation details. In a way, you could separate interfaces there, though. Random access methods (such as get and set) can be provided separately from sequential methods (first, forEach, map, rest, etc.) So perhaps the problem is that the List abstraction is not specific enough?

Can a function named

smthOrNull

throw

IllegalArgumentException

if its usage is incorrect? Or is it too confusing? What's the convention?

OrNull generally doesn't throw in the stdlib

@kirillrakhman: any examples when it does?

None that I know of

just noticed in the source:

public fun CharSequence.removeRange(range: IntRange): CharSequence = removeRange(range.start, range.endInclusive + 1)

is it not inlined intentionally?

No lambda or reified generic, why would it be inline? JIT is perfectly cool doing this, and confusing stacktraces and such is not good.

reducing the method count, etc

i don't know

@orangy: I rather disagree; one-liners like that should almost always be inlined

@eddie: okay simple smile

@orangy: I like to leave as little to chance as possible, which means assuming the JIT is dumb (or non-existent) simple smile

not to mention, in other environments methods like that would probably be inlined by the compiler regardless of whether it's tagged or not

@eddie: I neither agree, nor disagree with you. We can’t take “like” or “should” or “other environments" without strong arguments as a motivation to change anything in stdlib

very true

I think I just found the right solution:

A::class extends B::class

https://youtrack.jetbrains.com/issue/KT-11783 https://kotlinlang.slack.com/archives/stdlib/p1457533017000408

calling this from Java will be hard

Why would we use Java extends/super names in Kotlin? simple smile

@kirillrakhman: how KClass can be helpful from Java?

it was just a theoretical argument

What do you think about the following one liner:

inline fun <T> T.assuming(condition: (T) -> Boolean) = if (condition()) this else null

Example usage:

val lines : String? = file.assuming { it.exists() }?.readText()

We use this method but we call it

given