Channels
#announcements
- a
agrosner
03/08/2018, 2:00 AMInternal does the same thing but a larger scope - d
dumptruckman
03/08/2018, 2:01 AMtoo large of a scope👍 1 - a
agrosner
03/08/2018, 2:01 AMIf that's your worry you might as well go multimodule👎 1 - d
dumptruckman
03/08/2018, 2:01 AMthat's so much extra work - a
agrosner
03/08/2018, 2:01 AMIt's so much faster, easier to control dependencies - a
agrosner
03/08/2018, 2:01 AMNot if you set up a common build.gradle - c
christopher
03/08/2018, 2:02 AMAsk for package internal, and I’d vote for it. Not that it think it’s necessary. But sure, why not.👍 1 - d
dumptruckman
03/08/2018, 2:03 AMas @kirillrakhman said on the forumCopy codeIn my opinion it’s not about whether you can enforce a visibility rule 100% from a technical standpoint but about what the enforcement gives you and the users of your API. In the case of package private, the enforcement is too weak to prevent your users from breaking it (even without reflection) but it’s good enough to prevent the members from popping up in the completion list. Especially, when I’m the one consuming my own API (within the same module), I would be very glad to be able to hide the implementation details from the completion list while still being able to organize my code properly within the package.👍 1 - a
agrosner
03/08/2018, 2:04 AMYou group common things in same package you shouldn't have to worry about package private right - d
dumptruckman
03/08/2018, 2:04 AMadditionally, internal seems to make testing these hidden things impossible - d
dumptruckman
03/08/2018, 2:05 AMso i am forced to make implementation details public to test them - b
btilbrook-nextfaze
03/08/2018, 2:06 AMGoing multi-module is a huge amount of work, and entails much more boilerplate, and is therefore not a comparable alternative to package-private.👍 2 - c
christopher
03/08/2018, 2:06 AMUh... Tests shouldn’t be in a separate module - d
dumptruckman
03/08/2018, 2:07 AMthey're in the same package but internal doesn't care about that - d
dumptruckman
03/08/2018, 2:07 AMthis may only be a problem because i'm writing the tests in java - c
christopher
03/08/2018, 2:07 AMCorrection, I meant module - d
dumptruckman
03/08/2018, 2:07 AMbut still, it's a problem - d
dumptruckman
03/08/2018, 2:08 AMsrc/main/kotlin/package/CodeWithIntenal.kt src/main/java/package/TestThatCantReachInternal.java - c
christopher
03/08/2018, 2:09 AMHmm... I’d call that a bug in whatever is executing your tests - b
btilbrook-nextfaze
03/08/2018, 2:10 AMIdeally, favor testing public APIs. They make your tests less brittle. - d
dumptruckman
03/08/2018, 2:11 AMyeah, however a unit test on some non-public algorithm method may be needed - b
btilbrook-nextfaze
03/08/2018, 2:12 AMI understand it sometimes makes it easier, but the only thing that really matters is the public API meets its contract. The impl. details of the algorithm might not matter for the API consumer. - b
btilbrook-nextfaze
03/08/2018, 2:13 AMAnyway, I’ve encountered situations where testing an
detail helped. Maybe try converting your tests to Kotlin.internal - d
dumptruckman
03/08/2018, 2:13 AMCopy codeclass InternalTest { companion object { @JvmStatic internal fun test() { } } } - d
dumptruckman
03/08/2018, 2:14 AMThis autocompletes to
in my java test classInternalTest.test$production_sources_for_module_tiny_compiler(); - d
dumptruckman
03/08/2018, 2:14 AMand saysUsage of Kotlin internal declaration from different module - b
btilbrook-nextfaze
03/08/2018, 2:15 AMYep. By design. Kotlin tests should be able to access it without the mangling. - d
dumptruckman
03/08/2018, 2:17 AMbut the error? - b
btilbrook-nextfaze
03/08/2018, 2:18 AMIf you write the test in Kotlin, you won’t have the error. - b
btilbrook-nextfaze
03/08/2018, 2:19 AM*But as stated earlier, the tests need to be in the same module