Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module and Type name ambiguity #11

Open
jeanetienne opened this issue Nov 9, 2024 · 3 comments
Open

Module and Type name ambiguity #11

jeanetienne opened this issue Nov 9, 2024 · 3 comments

Comments

@jeanetienne
Copy link
Contributor

Hi Marcin, first of all thank you for your great work 🙏

I find myself in a weird case in my project. I have a class called Theme in my app code, and when I want to create a custom theme for the Neon plugin, it is impossible to make the compiler understand which class I want to instantiate.

  • If I call just Theme, it picks my class first.
  • If I call NeonPlugin.Theme to try to disambiguate, the compiler says "Type 'NeonPlugin' has no member 'Theme'" as it interprets NeonPlugin as the struct rather than the module.
  • I can't play with advanced import statements (e.g. import struct NeonPlugin.Theme) as my Theme class is part of the core project and still has precedence.

The only other solution I can think of is to wrap either some of my app code, or STTextView & plugin into its own swift package?

➡️ Would you be okay with me opening a PR to change the module name to something like STPluginNeon.

It would make for an easier disambiguation for anyone having similar issues where they have Theme or Colors classes in their project. They would be able to call STPluginNeon.Theme and the compiler wouldn't be confused with trying to find a nested type inside of the NeonPlugin struct.

I understand it's probably an annoying change, and probably for a rare case not many people encounter?.
Let me know what you think of it.

Related conversation

swift.org forum: Fixing modules that contain a type with the same name
There doesn't seem to be any tool to resolve this at the language level (yet?).

@krzyzanowskim
Copy link
Owner

it makes sense. The swift naming limitations bugs me. It is probably better to rip the band-aid off now than later. Please open PR

@jeanetienne
Copy link
Contributor Author

I opened a PR earlier today, and linked this issue for traceability.

@jeanetienne
Copy link
Contributor Author

Let me know if there's anything else I can do to help?

krzyzanowskim pushed a commit that referenced this issue Nov 10, 2024
Renamed the module `NeonPlugin` → `STPluginNeon` In order to avoid a
name collision with the main type `NeonPlugin`.
This in turn, allows for easier disambiguation for projects that also
have their own `Theme` or `Colors` type.

E.g. it is now possible to do this, even if your project has its own
`Theme` type:

```swift
import SwiftUI
import STTextViewSwiftUI
import STPluginNeon

extension STPluginNeon.Theme {
    public static let myCustomTheme = STPluginNeon.Theme(colors: [:], fonts: [:])
}
```

## Discussion
See issue #11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants