Can I disambiguate between something that's available on the Companion vs the class itself? ```class...

# compiler

[mbonnin]

Can I disambiguate between something that's available on the Companion vs the class itself?

class Foo {
  object bar {}

  companion object {
    val bar = "companion bar"
  }
}

// I can read the companion bar
println(Foo.bar) // companion bar
// How do I access the object bar?
println(Foo.??)

[Sam]

Nice question, I would love to know if there's a good answer to this.

println(Foo.bar) // prints "companion"
println(Foo.bar.toString()) // prints "Foo$bar@3fa77460"

How weird is that?
So my first suggestion is Foo.bar.let { it }. The IDE warns me I'm being stupid, but it works. Though I don't think I'd want to rely on it continuing to work in future versions...

[mbonnin]

Foo.bar.let { it } mind blown

[mbonnin]

Nice find! I wonder how future proof it is too!

[Sam]

Reminds me a little of KT-47412

[mbonnin]

Yup, really similar. The fact that it was fixed seems to indicate that this is a supported use case

[wasyl]

Foo::class.nestedClasses.single { !it.isCompanion }.objectInstance as Foo.bar

🧌

[wasyl]

I’m curious what’s the use case here — generally classes should start with an uppercase, so I’d expect Foo#Bar and Foo#Companion#bar. Clearly since you’re asking you have a reason to distinguish those, I’m just curious

[mbonnin]

Generated code coming from GraphQL

[mbonnin]

And we can't really uppercase everything because bar and Bar can be two different enum values...

[wasyl]

Ah, the classes name are user input basically 👌 And I assume you have to be consistent with GraphQL spec which allows that?

I’d consider something like _bar for the lowercase variant if there’s a collision. #notHelpful

[mbonnin]

Yep, we might end up doing that. We're doing it for name and ordinal already which are not allowed in kotlin enums. Was just curious if there was a better fix

[wasyl]

If you open an issue for this problem please link here, I’m very curious if there’s a kosher way to get both `bar`s here. The let { } seems like an implementation detail? toString() too, like function calls prioritise types, but raw Foo.bar prioritises properties mind blown

[dmitriy.novozhilov]

Please report it in kotl.in/issue

[mbonnin]

https://youtrack.jetbrains.com/issue/KT-52573/Identical-names-on-both-the-Companion-scope-and-the-class-scope-compile-but-are-hardly-usable

[hfhbd]

What about importing the class as a more stable workaround?

[mbonnin]

@hfhbd how would you import it? I can do

import Foo.bar as companionBar

But that still resolves to the companion. In the imports or in the code the problem is the same

[hfhbd]

I mean this 🤔:

import Foo.bar

class Foo {
    object bar {}

    companion object {
        val bar = "companion bar"
    }
}

fun main() {
    println(Foo.bar) // companion bar
    println(bar) // Foo$bar@58644d46
}

[mbonnin]

Ah, interesting! I'm almost sure I tried this and import Foo.bar was resolving to companion bar ...

[mbonnin]

MMmm seems to work now, not sure what I did but yea, that would work too!