I have pushed the initial code for the KFile proje...

# multiplatform

[pajatopmr]

I have pushed the initial code for the KFile project, my attempt to provide a library that provides a canonical Kotlin file class for JVM and Native platforms. https://github.com/pajato/KFile

[msink]

I think Native implementation can be adapted from scala-native:
https://github.com/scala-native/scala-native/tree/master/javalib/src/main/scala/java/io

[pajatopmr]

I will check it out. Thanks.

[thevery]

GPL :(

[msink]

OK, then avian https://github.com/ReadyTalk/avian/tree/master/classpath/java/io
BSD-like license

[juancho]

Why did you choose to make KFile an interface and not an “expected” class?

[pajatopmr]

Mostly historic. I started off just to build a TextFile interface and that morphed into a KFile interface. Why do you ask? If I am missing something, and I easily could be, it would be good to know.

[pajatopmr]

Actually a better answer is that I am partial to: a) interfaces and abstract classes over concrete classes, and b) factory methods over constructors.

[russhwolf]

Using interfaces in a library makes it easier for clients to mock the library out when they want to test their own logic in isolation.

[Dico]

Does kotlinx-io library not have a multiplatform file manipulation api?

[Dico]

I guess not

[juancho]

Thanks @pajatopmr! I just asked for curiosity, I’m still learning about Kotlin multiplatform and I feel a little lost in these cases to define something as “expect class” or interface. Thanks!

[pajatopmr]

@thevery GPL was a mistake. I meant to use LGPL in case it matters. I will fix this on 0.0.2.

[thevery]

Of course it is your choice, but lgpl limits usage, too. Why not APL as most other libs and kotlin itself?