The lowercase-enum trick composes well* with static dynamic member lookup + static key paths to build a platform-agnostic design system full of constants that can then get projected to the platform type.
*subjective
I made a document on my website to catalog the lowercase enum idea.
https://kylehugh.es/documents/swift-namespace-lowercase-enum/
@miguelcabeca @mattiem Not too much work, no.
But, technically, this needs to be a `struct` so it can be instantiated. And then it needs a private initializer to communicate that it shouldn't be instantiated outside of this limited scope. So now this has become a many-step pattern every time we want to replicate it. Things to remember, things to get wrong, levels of misdirection.
What I proposed, although it has its own edges, minimizes the levels of misdirection and the number of rules.
@kyle @mattiem ok, I gave it one more try, this time in front of a computer in Xcode instead of typing in my phone. What about this?
extension TimeInterval {
public static let animation = Animation.self
public enum Animation {
public static let `default`: TimeInterval = 0.25
public static let minorTweak: TimeInterval = 0.15
public static let pop: TimeInterval = 0.35
}
}
@miguelcabeca @mattiem That’s clever. Its implementation still has more ceremony and is unconventional in its own right—a middleman property that exists to exposes a type.
That’s how I ended up where I did: every solution to this “problem” is unconventional, and I found the friction from remembering the implementation patterns to be slightly too much, at scale. With my proposal (?), one has to get over one piece of misconvention, but everything else is self-evident and memory-free.