I've noticed a 'new' (to me) workflow/convention in IntelliJ, whereby this `expect` / `actual` wizar...
d
I've noticed a 'new' (to me) workflow/convention in IntelliJ, whereby this
expect
/
actual
wizard creates actuals with the convention
<name>.<platform>.kt
. I'm familiar with the need to disambiguate the file's JVM name at times; is this naming convention a clear resolution on that problem? Is it documented anywhere? Thanks.
๐Ÿ‘€ 1
a
If only theyโ€™d nest into the same file with sub tabs or same subsection ๐Ÿ˜ž
d
@agrosner Yes, a 'coalesced view' of Multiplatform source-sets would be great - hopefully with the increased focus on MPP something like that isn't far away...
m
I like the new naming scheme overall but it's annoying that creating a new file like
URL.desktop.kt
creates a
desktop.kt
file in the
URL
package ๐Ÿ˜’
d
Can't say I've seen that happen yet @mbonnin
(And by the way I am using Ktor's common
Url
this was just a contrived example)
m
Happens consistently for me when creating new files from the "Project" window
But it's an older thing, the new naming thing just makes it more often to be encountered
j
I'm curious, are recommended KMP file naming standards documented anywhere explicitly, like for JetBrains' kotlinx libraries? Like what should extension files be named and when might you prefix a file with
-
? I've seen different conventions in many libraries. I've also noticed kotlinx libraries often don't use the standard source set file structure, opting for
module/common/src
and
module/jvm/test
, for example. Maybe that's just legacy, but it's actually nice having main and test source sets grouped together. I've just been coming up with my own file naming without putting much thought into a good standard for my own libraries. It'd make sense to standardize on something more widely accepted. I've definitely run into the JVM filename collision error often myself, so I may adopt this
name.platform.kt
pattern.
m
when might you prefix a file with
-
?
That's when you want to hide your API from Java. This makes sure the
-FooKt
file can't be called from Java
j
Oh, good to know. Thanks.
m
I commented about the part I knew about ๐Ÿ˜„ . But +1 to having naming standards/guidance there.