On 10 Aug 2016 15:01, "Nick H" <[email protected]> wrote: > > It's left over from when Graphics was part of core. It does seem strange that it wasn't moved to evancz/graphics along with Collage and the rest.
I think it's useful beyond evancz/graphics, eg. I use the color functions with WebGL. > > On Tue, Aug 9, 2016 at 9:32 PM, Robin Heggelund Hansen < [email protected]> wrote: >> >> I recently read the documentation for elm-lang/core, and was a bit puzzled to find a Color module in there. This in turn, made me come up with a series of questions. >> >> * Is Color a core concern? >> I would say no. In my projects (not only in Elm) I have yet to find need of a Color module (would probably be different if I didn't keep css in .css files). That's not to say that I'm representative of Elm developers at large, or that Color isn't useful, I just don't think it has a place in the core package. One could argue that Elm is about frontend development, which has to do with UI, which again has use of Color. Sure. But Html and Http, the perhaps most important modules for frontend development are not in the core package, so why should Color be there? >> >> * What are the downsides? >> The core package is required in every project, this means that core is compiled in every single Elm application. One could argue that the core package should be as small as possible, because Elm developers shouldn't pay for what they don't use. One could also argue that having Color in core poses an increased maintenance burden on the core developers, who are already overworked as it is. While true, none of these arguments pose a big deal, because: >> >> 1. Color is probably (not tested) not so big that it has a noticeable effect on compile times. >> 2. Unused code is easily stripped away by a minifier like UglifyJS. >> 3. The Color module is pretty complete, and I don't see it changing much in the future, so the maintenance "burden" is probably very small. >> >> * What are the upsides? >> It's probably valuable to have a de-facto Color module for Elm (again, I don't make use of it so I don't know). On the other hand, all other modules which would be good to have as the "one, true" module are external modules (websockets, http, html...). >> >> * Do you have a paper thin argument? >> Sure. Having modules in core that don't fit the "core concern" description opens the door for discussing adding more modules which also don't match the "core concern" description. Evan and other core developers are pretty good at saying no though, so I'm not worried about this. >> >> * What would I propose? >> I propose that Color should be moved from the core package and placed in a package of its own. There are advantages to doing this (though marginal) and I believe it outweighs the disadvantages (those who use Color have to add a line to their elm-package.json). It's not an important change, and shouldn't be a priority, but I still think it should be made. >> >> What do other people think? >> >> -- >> You received this message because you are subscribed to the Google Groups "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
