Bothered by the fact that all @Compose UI components are in the Global namespace. As someone who do...

# compose

[Ash]

Bothered by the fact that all @Compose UI components are in the Global namespace. As someone who does not start a project without DI and a clear Architecture this keeps bothering me. SwiftUI & Objective-C same issue How are people handling working in super large teams with name clashes ??? Wrap everything in a companion object just to get the namespace? Wondering if missing something ...

[Robert Menke]

Not sure what the issue is here. There’s no naming conflict as long as 2 components don’t have the same name in the same package.

[Ash]

True ... so do you just wrap it in a companion object if it is in the same package?

[Ash]

We have a ton of @Composables in our maps package and people keep adding to it ...

[romainguy]

@Ash Composables don’t have to be top-level functions, and they can be put in different packages

[Ash]

So true ... but there are only a certain number of ways to say "DriveInfo" in the Maps Package 🙂. Should we put all @Composables in companion object for the name space? I would hate to build/move packages just because of name conflicts. We have a ton of name clashes in our maps Package 😢

[Se7eN]

Wrapping everything in an object won't be a good idea because the JVM would be creating objects you don't need

[Se7eN]

It's actually a Kotlin problem since it doesn't support namespaces like C++

[romainguy]

You have packages though…

[romainguy]

Overloads too, you have have multiple functions of the same name with different parameters

[Ash]

For now we will have to live with name clashes on merge as we believe keeping @Compose as top level function is best practice. We are waiting to see what Android & Dagger Hilt Team does with @Composable DI and/or hope one day Kotlin adds namespaces 😿 ... https://arturdryomov.dev/posts/namespacing-in-kotlin/

[Se7eN]

But there are still packages. Like map.drive in your case

[Ash]

But ... I hate to tell people to move code just because of name conflicts ... wish we had name spaces in Kotlin. In SwiftUI we use enum ... Should be a way to merge code into same package and not have to worry about name clashes?

[gildor]

Package is a part of the name, same as namespace, I see nothing wrong to be careful with package name, it's important to keep code manageable and as you said avoid name conflicts

[gildor]

Wrapping everything in an object won't be a good idea because the JVM would be creating objects you don't need

It's not a problem at all, companion object also create an object

create objects if it makes your code more manageable, you don't need any special Dagger/Hilt support for it

[Ash]

I was just told Kotlin is adding namespace ??? Is that true ??? If so we are done!

[Se7eN]

Where did you see that? I don't think it's true

[gildor]

See this part of the video:

https://youtu.be/0FF19HJDqMo?t=422▾

[gildor]

But honestly I think it would change nothing for Siamak

You can do exactly the same with companion objects

[gildor]

so exactly what was suggested above in this thread

[gildor]

namespaces just allows to have multiple namespaces for the class and doesn’t require companion object

[gildor]

but it not a problem for your use case