It's left over from when Graphics <http://package.elm-lang.org/packages/evancz/elm-graphics/1.0.0/> was part of core. It does seem strange that it wasn't moved to evancz/graphics along with Collage and the rest.
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.
