File class

[altavir]

File is a really problematic thing in multiplatform since it means completely different thing in JS. Also File is more or less obsolete in java, it is better to use Path and nio instead. It requires a lot of thinking. JB people probably already thought about it. Need to search the tracker.

[altavir]

The problem seems to be even more complicated, so File api is currently out of the question. I think, the best that could be done is collaboration with kotlinx-io team about some common ground. Like getting input and output streams by string reference.

[lamba92]

File is a really problematic thing in multiplatform since it means completely different thing in JS. Also File is more or less obsolete in java, it is better to use Path and nio instead. It requires a lot of thinking. JB people probably already thought about it. Need to search the tracker.

I agree that a path-centric would be better. Have you any link to JB stuff?

[altavir]

I do, but this problem is currently above our pay grade. Could you write what you currently want from file API? We probably could construct something that will cover basic needs without inventing something complicated that will be replaced in any case.

[lamba92]

• reference a path regardless of the slashes directions. <-- n°1 priority i guess
• check if the file exists in that path
• get name without extension and get extension if any
• delete it, create it
• write lines, read lines, iterate over lines
• read/write stream chuncks in binary
• read/write metadata such as creation date, ecc (boy this need platform specific stuff)

I thing that trying to bind it to the Java stdlib would be a bad idea. First of all I'd go for a path system that expects stuff from its kotlin backend implementation

[altavir]

Ouch. Do you understand that most of it won't work in browser JS?

Also multiplatform does not have APIs for byte streams.

[lamba92]

I would focus on NodeJS first. We could always add later in the JS module a version of the class truncated with what does not work in the browser. Furthermore you can just add a check at runtime if you are in browser or NodeJS so that it throws an exception.

[altavir]

Currently the general rule is to avoid adding to common something that fails on at least one of supported platforms. We can try to create node and native experimental implementations and then see if we can generalize them.

I will look into it later.