-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
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 |
I opened a PR earlier today, and linked this issue for traceability. |
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
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.Theme
, it picks my class first.NeonPlugin.Theme
to try to disambiguate, the compiler says "Type 'NeonPlugin' has no member 'Theme'" as it interpretsNeonPlugin
as the struct rather than the module.import
statements (e.g.import struct NeonPlugin.Theme
) as myTheme
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 theNeonPlugin
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?).
The text was updated successfully, but these errors were encountered: