Re: [elm-discuss] Should Color be a part of core?

[Nick H]

The color data needs to be translated to a Vec4 before being sent to a
shader. So this library isn't a particularly good fit for working with
WebGL.

The types were written to be used with evancz/graphics. The gradient stuff
is completely unusable by anybody else, since the Gradient type is opaque.
The Color type is also opaque, but you can get out the data you put into
it, and it is useful for converting between RGB and HSL.

But regardless of the usefulness of the library, I agree with Robin that it
looks out-of-place in core.

On Tue, Aug 9, 2016 at 10:33 PM, Conrad Parker 
wrote:

> On 10 Aug 2016 15:01, "Nick H"  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 <
> skinney...@gmail.com> 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 elm-discuss+unsubscr...@googlegroups.com.
> >> 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 elm-discuss+unsubscr...@googlegroups.com.
> > 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 elm-discuss+unsubscr...@googlegroups.com.
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Should Color be a part of core?

[Conrad Parker]

On 10 Aug 2016 15:01, "Nick H"  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 <
skinney...@gmail.com> 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 elm-discuss+unsubscr...@googlegroups.com.
>> 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 elm-discuss+unsubscr...@googlegroups.com.
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Should Color be a part of core?

[Nick H]

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.

On Tue, Aug 9, 2016 at 9:32 PM, Robin Heggelund Hansen  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 elm-discuss+unsubscr...@googlegroups.com.
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Should Color be a part of core?

[Robin Heggelund Hansen]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.