Make more methods public

[dvkch]

Hi there,

Would it be possible to make more components public, or add public extension methods, mainly to obtain the HSLuv components of a UIColor/NSColor object ?

Thanks for considering

[boronine]

Fellow contributors - @robotive @stphnclysmth @jaywardell @nickswalker - could you offer advice?

I looked at this repo again after receiving a PR with more initializers: #17 (cc @jaywardell)

Why are we monkey-patching platform APIs (UIColor, NSColor) instead of exposing our conversion functions? Is this idiomatic Swift? I am tempted to get rid of all platform code and make this library pure and buildable on Linux / Windows and not dependent on XCode or Apple.

Instead of monkey-patched initializers we can just offer instructions in the README like this:

import HSLuvSwift

let rgb = hsluvToRgb(hue, saturation, lightness)
let color = UIColor(red: rgb.R, green: rgb.G, blue: rgb.B, alpha: 1.0)

Thoughts?

[jaywardell]

From my perspective, making the conversion functions public would work just as well as my additions. Of course, it’s easy enough to do both: make the functions public AND offer conditionally compiled extensions on platform-specific types.

[jaywardell]

If you wanted to expose the conversion functions, I could make a separate package that imports hsluv-swift and offers the platform-dependent initializers. It would mean removing functionality from the original framework, but it would be easy enough to point folks to the second package.

We could separate functionality between:
hsluv-swift: core functionality
hsluv-UI: platform-dependent initializers

When I was doing the SwiftUI initializers, it occurred to me that there could be a more idiomatic SwiftUI way to do things (eg using the Angle type) if I weren’t trying to maintain consistency with the other initializers. If the packages were split, that would be simpler to do.

lmk