avh4 / elm-color

Standard representation of colors, encouraging sharing between packages. (This replaces elm-lang/core#Color from Elm 0.18.)
BSD 3-Clause "New" or "Revised" License
23 stars 6 forks source link

`fromHex` is not exposed #20

Open francescortiz opened 5 years ago

francescortiz commented 5 years ago

fromHex is not exposed. It looks like a bug.

davidjb99 commented 5 years ago

According to this commit, it has been removed in v1.0

https://github.com/avh4/elm-color/commit/5627d0134f6f50e26fe553b2abbc5b33f0870bea

The code still works as far as I can tell.

janwirth commented 5 years ago

It's not a bug. It's really not useful.

francescortiz commented 5 years ago

It's not a bug. It's really not useful.

I have lists of hex colors everywhere. Hex can be copy/pasted. Hex can be stored in database in a consistent form across many environments. What is the reasoning behind fromHex not being useful?

janwirth commented 5 years ago

Sorry I meant that making fromHex private is not useful. fromHex itself IS useful.

dpinn commented 5 years ago

Arrrrgh! Me want too.

francescortiz commented 5 years ago

elm-color-extra provides a fromHex function. It is weird though having to use an external package for a function that is already defined. Then, if elm-color-extra has this function and is the one that is supposed to be used, maybe elm-color should have elm-color-extra as a dependency... but then elm-color-extra depends on elm-color... does not make sense. I can't find any logic in not exposing fromHex.

AsbjornOlling commented 4 years ago

same goes for toHex :(

I think it may be to prevent people from using toHex instead of toCssString for that particualr use case - but RN I'm making a toy color picker, and I'm gonna end up just implementing an identical function myself. Seems silly.