Bothered by the fact that all @Compose UI componen...
# compose
a
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 ...
r
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.
a
True ... so do you just wrap it in a companion object if it is in the same package?
We have a ton of @Composables in our maps package and people keep adding to it ...
r
@Ash Composables don’t have to be top-level functions, and they can be put in different packages
✔️ 1
a
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 😢
s
Wrapping everything in an object won't be a good idea because the JVM would be creating objects you don't need
😞 1
✔️ 1
It's actually a Kotlin problem since it doesn't support namespaces like C++
✔️ 1
r
You have packages though…
☝️ 1
Overloads too, you have have multiple functions of the same name with different parameters
2
a
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/
s
But there are still packages. Like map.drive in your case
✔️ 1
☝️ 2
a
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?
g
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
☝️ 1
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
a
I was just told Kotlin is adding
namespace
??? Is that true ??? If so we are done!
s
Where did you see that? I don't think it's true
g
See this part of the video:

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

But honestly I think it would change nothing for Siamak You can do exactly the same with companion objects
so exactly what was suggested above in this thread
namespaces just allows to have multiple namespaces for the class and doesn’t require companion object
but it not a problem for your use case