Redeclaration clash with private classes

I noticed that two private declarations of classes with the same name (in different files) nevertheless yield a redeclaration clash in IntellIJ. The documentation is absolutely clear about the visibility of the declarations and that they are only visible within the same file.
What am I missing?
File1:
package somePackage
private class A
File2:
package somePackage
private class A

2 Likes

Should have done some more research first.
See kotlin - Can’t create private classes with same name in different modules - Stack Overflow.
‘Visibility’ is not the same concept as ‘Identity’. You can only have classes with the same name if they are in different modules (i.e. compiliation units).
Would be nice if I could freely chose a class name in some file without having to bother this colliding with some other class in the same module but otherwise potentially far away from a subject matter perspective.

I’m not sure why you want to do that as you didnt detail your use case. But if you want to use it only in that file did you look into inner classes?

In my experience this is used to provide an implementation for a public interface, without making the underlying class visible to the consumer of the library. Examples for this are the different List implementations in the std-lib. Most of the time it will use the java implementations but I think there are special, optimized versions for an empty list and a list with only 1 element.

The use case is as follows. Say I am exploring some idea and have several versions of it in work in parallel. So I open a new file and call it for example 'Version04". Then I introduce the same class (at top level) as shown above as a routine and start writing functions. By the way: I do not have a collision with function names, as long as I mark them private.
So, I could definetely introduce a class “Version04” and have the rest within that class. But it would over time lead me away from using top level objects in general. I think the ‘private’ marking should be more effective in keeping anything marked as private just that: private and never visible or effective in any way outside the file.
I understand the behaviour now a bit better and there might be some underlying architectural reason, why it can’t be different. I just wonder why it is implemented that way and would like to understand why.

It is not a problem, when the two files are in two different packages at least. That should conclude this whole thing. Thanks to bjonnh and Wasabi375 for even bothering to respond to this.

1 Like