WIP: Don't typealias Month

[wkornewald]

This is just one example from the codebase. Why are so many APIs expect and why do we even try to use typealias at all? This makes it more difficult to define a nice API for Kotlin and it causes lots of code repetition. It's even impossible to use sealed interface/class with expect/actual because the multiplatform code lives in different modules (see #173, #177 and #175 for how this can be useful).

I think it would be much better to separate the expect APIs and make them internal and expose a nice and clear non-expect based public API (which can call the internal expect API inside).

What do you think?

[wkornewald]

@dkhalanskyjb Closing this PR. Is it even worth discussing in a separate issue? This could be a general architectural discussion and the Month typealias is just one aspect of the way expect/actual is used.

[dkhalanskyjb]

There's an issue for it already: #96

[wkornewald]

Not quite. That only focuses on the Month typealias. My suggestion is to generally apply the rule: avoid expect + public because it leads to problems like sealed not working (maybe the only exception is expect public fun which might be always ok?). Try to use expect only with private and internal.

[dkhalanskyjb]

The library is fairly compact, so its internal architecture can be changed on a whim once we need it and does not matter much. What matters is the API that we provide to the programmers, and they typically shouldn't care whether something is expect or not.

actual typealias has actual issues on that front: #96 (comment). Do you see any potential issues for the programmers because of, say, LocalDate being expect?

[wkornewald]

The library is fairly compact, so its internal architecture can be changed on a whim once we need it and does not matter much. What matters is the API that we provide to the programmers, and they typically shouldn't care whether something is expect or not.

actual typealias has actual issues on that front: #96 (comment). Do you see any potential issues for the programmers because of, say, LocalDate being expect?

I don't think there's any similarly fatal issue. The other issue is that this whole library can't use sealed which limits the API design in general and indirectly affects how comfortably programmers can work with this lib. At least one can't easily provide a FlexibleDate/FlexibleDateTime in this lib and I find that unfortunate because we keep reinventing the wheel.